High-Fidelity: From Wireframes to Comps

Sep 16
6

In this post, we discuss some of the basic steps we typically use to create compelling visual design compositions or mockups from the wireframes developed by our IAs. Ideally, a visual designer should be involved with a project from the onset. However, the reality for a service firm like ours where we are usually running multiple projects simultaneously, is that the graphic designers often begin their magic only after the wireframes are nearly finalized.

We have tried to create a format for our wireframes that leaves a lot of room for interpretation and exploration by our visual designers. Otherwise, it would be too easy for an inexperienced visual designer to fall into trap of merely coloring the wireframes. Dan Brown has a good article on Boxes and Arrows about how he has evolved his IA documentation to avoid being overly prescriptive.

Good design documentation and open, regular communication between the IA team and visual designers will help everyone know how literal the wireframes are intended to be and how much leeway there is in translating them into visual design comps.

Without further ado, we’ll share with you how we transform wireframes into compelling compositions. We’ll use a sample wireframe (shown below) illustrating an application to create and manage trip itineraries as a starting point.

1. Get everybody into the mood (board)

Originally used in advertising, mood boards have become an important tool for creatives to communicate the overall visual design direction or aesthetics (“mood”) of a user experience. These boards are typically created as posters with samples of text, images and other sample objects (materials, widgets, etc.) to help the client understand and internalize the emotive appeal of different proposed design directions. Once developed, mood boards can then be used as reference through the rest of the design process.

To create effective mood boards, first understand the stakeholder vision and goals of both users and client, making sure to focus of the emotional attributes of their desired experience. Answer the questions: What applications do they currently use? Who are the main competitors? What designs do they admire? Then study the brand attributes that are important to the client.

Look at the company logo, print collateral, brand guidelines (if available), and understand what are the essential company values (e.g. honesty, credibility, trust, fun, excitement, etc.). Understanding those values will help you choose appropriate color palettes (as well as, typography, images, etc.) for the application. Colors have meaning: use that meaning to your advantage. For example, blue represents trust, loyalty, wisdom, and truth; green represents growth, harmony, freshness, and money. If time and budget permits, a poster session with the client is also very helpful. We bring cutouts from magazines, sites, ad campaigns to reflect the above characteristics. After a couple of rounds of ratings, we can narrow to 2-3 color palettes.

In the end, emphasize the brand attributes through a rough layout of page with scattered standard widgets/elements of navigation, form, button, link, text, images and icons. We spend time combing through websites like istockphoto, corbis, shutterstock, and gettyimages for the perfect images and icons. This is also a good time to experiment with some typography variations. Generally, we don’t use more than two font families (primary and secondary) for any particular application.

Name your mood boards to reflect the overall theme represented — modern, classic, gaudi, or fluid. Getting very creative with the naming process (e.g., “Eames” representing a mood board that has a 1950’s mid-century modern aesthetic or “Deadwood” representing a gritty, dirty, Wild West aesthetic) can help the entire team understand the intended look-and-feel. A couple of variations of the mood boards we created for our itinerary application (see above wireframes) are shown here.

2. Classes, templates, and widgets

Now, get under the skin of the wireframes and understand the entire application – its context, key tasks and functionalities. Also, familiarize yourself with the various design decisions that were made throughout the wireframing process. For instance, why are tabs preferred over collapsing show/hide panels or why should scrolling be avoided on a critical page. This is especially important for visual designers who are brought in during the late stages of a project.

Then, identify broad layout, typography and color scheme of different page classes (forms, search results, popups or help). Next, extract the key page elements and widgets (data table, menu, navigation, login, form field, button) from the wireframes to complete a main task flows divorced of any page class.

Start designing the important sets for icons and buttons, charts and info graphics in this step to ensure consistency later on. We like to create many of our assets as vector graphics so that they can be easily scaled for different sizes and situations. The standard tenets of visual design should obviously be kept in mind while doing this.

At the end of this step, you should have a set of empty page classes with areas marked for masthead, navigation, primary content, secondary content, and so on. And a set of widgets indicating the primary task flows through the application. The included examples below provide a glimpse of this. More often designers skip this step in their haste to begin screen-level design. This myopic perspective — not seeing the forest for the trees — will ultimately result in many more iterations to get to a good design solution.


3. Some assembly required

Now it’s time to assemble the assets into screen compositions or mockups. We do this by matching the page classes with the widgets we’ve created and filling in the missing pieces. Identify several unique or key pages from the entire deck of wireframes to mockup. Then start with the most complex page first, to solve any design complexities sooner than later. Usually, design approaches on most complex pages scale down to simpler pages as well.

Screen resolution is also an important decision here. Usually, determine the requirements for screen resolution by looking at your web analytics, user demographics and more universal web statics. Then try to use proportions instead of fixed measurements to allow for a “liquid” layout. This will help your design easily accommodate higher resolutions and degrade gracefully for lower ones.

We usually choose a couple of very different pages from deck initially to render them in 2-3 different layouts and styles (based on the mood boards). We let the client pick a single direction before tackling the rest of the pages.


Conclusion — Science and Art

Visual design is really the secret sauce that can make or break a user’s experience with your application. We have all encountered an interface that wasn’t quite fully designed where its flaws are consequently amplified. We’ve also enjoyed those experiences where the beauty of the design persuades us to forgive minor usability issues. Here, we’ve tried to briefly explain the process or science that we employ to convert solid wireframes into compelling mockups. The art lies in your skill and imagination.

Posted by: Nishant Jain
6 Comments
  1. viraj deo

    May 5, 2010 - 04:47 AM

    an interesting read i must say… quite like the way the whole process is described.

  1. Erin Young

    Jun 6, 2010 - 12:51 PM

    One approach that I’ve always wanted to try is to run brand/aesthetic explorations simultaneous to user experience planning then to dovetail the two when each is locked. In my mind, it seems an ideal way to do things but I’ve yet to get buyoff on a project plan arranged that way.

  1. njain

    Jun 6, 2010 - 12:28 AM

    You are right Erin. That indeed would be an ideal way to go. However, practical considerations of juggling several projects together make it difficult to run a brand exercise in parallel with the interface design.

    We do try to include some of the brand impressions from existing collaterals in our stakeholder interviews, personas and scenarios.

  1. Jeff Swartz

    Jun 6, 2010 - 10:28 PM

    Appreciate the look into your process. Very interesting.

    I think some of our workflow is fairly similar, but given that a lot my company’s work involves brand standards that have to be meet, the visual design phase tends to be more an exercise of refinement rather than exploration.

    We’re probably guilty of designing too much during wireframing, but it certainly does help streamline things in the front-end process before development.

    Your “mood boards” are interesting. Not quite what I expected when I saw the screenshots. Isn’t something we generally do (see brand standards above), but I get it.

    At what stage do you begin coding? After the visual design, or do devs get involved earlier? We’ve been having discussions around that lately with our UI dev team.

  1. njain

    Jun 6, 2010 - 11:20 PM

    Completely understand where you are coming from Jeff. In about half of our projects we over-wireframe too, and focus only on brand consistency and aesthetics during visual design. In other projects, where we are given more creative license and have little or no legacy baggage, we try to scale down the wireframes, while allowing the visual designer complete control over structure or layout of the page.

    To answer your question, we actually don’t code at all, apart from creating prototypes (both with re-usable code like Catalyst or Expression, or otherwise in Axure) and front-end CSS/XHTML templates. The client is usually responsible. We deliver a packaged UI specs as the final deliverable. Although, dev team is part of the stakeholder group early. And they normally start laying down system architecture when wires are close to final.

  1. Val

    May 5, 2015 - 03:50 PM

    I need assistance with my web design. I have done the sketch on paper, next stop is wireframe which i am already involved with but I keep getting new ideas. Do I need to do a mockup before hiring a code writer since i don’t know how to write any code.
    Need advice. Thank you.

Leave a Comment