{"id":1075,"date":"2012-05-15T23:23:08","date_gmt":"2012-05-15T23:23:08","guid":{"rendered":"http:\/\/intercom.com\/blog\/?p=1075"},"modified":"2020-07-30T13:04:22","modified_gmt":"2020-07-30T12:04:22","slug":"wireframing-for-web-apps","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/wireframing-for-web-apps\/","title":{"rendered":"Wireframing for Web Apps"},"content":{"rendered":"

The goal of preparing wireframes is to solve design challenges regarding layout, and priority. This is usually done in wireframes through experimenting with layouts and the application of contrast, similarity and some other principles.<\/p>\n

<\/p>\n

By applying the Gestalt principles to your components, you can quickly prepare concepts. The whole point of working at this fidelity is the speed at which you can explore ideas with a reasonable degree of precision. Over the years I\u2019ve learned some useful ways to keep things fast, useful and timely. I\u2019m loathe to write a \u201c7 top tips for wireframing\u201d but when working with less experienced designers I find the following themes occur frequently…<\/p>\n

1. Everything means something<\/h2>\n
\"\"<\/div>\n

Every colour, every line, every shadow, every gradient. If your atomic unit of wireframes is a rectangle, with solid lines, a colored background and a drop shadow you\u2019re communicating a lot, whether you intended to or not. These artefacts can be carried through to design, without anyone ever thinking why they make senes. Everything has to mean something.<\/p>\n

2. Consistency Helps<\/h2>\n
\"\"<\/div>\n

One nice thing about sketching, is that it defaults to same colour and font everywhere (i.e. you have to swap markers or change your handwriting for a difference). A frequent issue I see with wireframes is numerous different shades of a colour, or line weights, or font faces, all included without thought. This makes the wireframe more confusing to understand, as I wonder \u201cDid he deliberately change font here? Is that label bigger because it\u2019s more important?\u201d etc. To avoid this, I encourage students to use a limited color set (3-5 grays), 2 fonts, default HTML components, and little else. This might result in \u201cdull\u201d wireframes, but bear in mind all wireframes end up in the trash anyway. They\u2019re not what counts, you\u2019re not delivering a PDF for visitors to \u201cooh\u201d and \u201caah\u201d at, you\u2019re desigining software for people to use. A sexy wireframe is a waste of everyones time in the project.<\/p>\n

A second point worth noting here is where you lay your baseline. Starting with black text, means you can only get bigger and bolder, resulting in a Deep Purple style wireframe with everything louder than everything else. Starting with gray text, allows you to go darker and lighter. As Ryan Singer<\/a> said, in a moment of Linguistic Relativity<\/a>, HTML doesn\u2019t offer a <weak> tag, but maybe it needs one.<\/p>\n

3. Speed and Exploration<\/h2>\n
\"\"<\/div>\n

The purpose of low fidelity design, is not to polish and refine, but to explore the solution space. Initially it often appears there are many solutions to a design challenge. Only by exploring a few of them, and laying them out in front of you can you decide which will work best. Cennyd Bowles describes how chess players face a similar challenge<\/a>. Early in the game there are a lot of choices. Some you can rule out by instinct or experience. The remainder you mentally explore to see how they play. Na\u00efve designers will fall in love with their first idea and cling to it for dear life. Andy Rutledge describes this phenomena an Lord Of the Rings inspired essay title My Precious<\/a>.<\/p>\n

If you can\u2019t produce concepts quickly, then you\u2019re working at the wrong fidelity. If your wire-framing serves only to deliver a grayscale version of what you\u2019ve already decided you\u2019re building then you\u2019re wasting everyones time.<\/p>\n

4. Real Copy, Real Data<\/h2>\n
\"\"<\/div>\n

The biggest mistakes I\u2019ve seen made in projects (including my own) comes from the designers not seeing real content up front. If you\u2019re including a photo gallery, you have to see the photos before you can decide whether to include it, make it a primary feature or fight against it. Similarly If you\u2019re designing a data driven dashboard, you need to know the data looks like. Dummy data leads you into a world where headings never wrap, text can justify without looking absurd, photo dimensions and orientations are always convenient, and numbers always fit in their little boxes. The path to UI hell is sign posted \u201cLorem Ipsum\u201d.<\/p>\n

5. Know your technology<\/h2>\n
\"\"<\/div>\n

A great design can be a terrible solution. If your design includes custom HTML components, novelty size buttons and dropdowns and ajax powered live search, it\u2019s worth remembering that every project has a budget. If you know HTML\/CSS\/JS, which you should, and you\u2019ve seen what it takes to test a page on IE6\/7\/8\/9 Safari, Chrome and Firefox, you\u2019ll think twice about what wizardry you\u2019ll put in your wireframes. It might just a little component, and it might even be already available in jQuery UI, but remember, there are no small changes<\/a>. I\u2019m not saying that you should never include advanced interactions in wireframes, I\u2019m saying you need to know the cost of what you\u2019re doing. For Hipmunk<\/a> it\u2019s worth investing weeks, even months of work into the best possible calendar picker, as it\u2019s the guts of the interaction. In that case the trade-off is worth it. It\u2019s when I see a fancy date picker for date of birth, or a very precise Javascript powered time picker that I think the designer should first talk to the developer.<\/p>\n

6. Whatever Works<\/h2>\n
\"\"<\/div>\n

The goal is great delivery, not great deliverables. No one marvels at great deliverables except other UX designers, and even then they\u2019re only interested when the end result was solid. If you\u2019ve sketched something on a whiteboard that you\u2019re confident is a good feasible solution, that has real data in it and everyone in the project knows what precisely what you mean then there is zero value in re-creating your whiteboard as a wireframe. Don\u2019t be a slave to deliverables.<\/p>\n

Other resources<\/h2>\n

These are lessons learned both through personal trial and error, and also from lecturing and seeing the materials that students present. Here’s a short list of excellent posts about wireframing<\/a>, sketching and designing.<\/p>\n