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.