The (mis)understandings between Web Designer and Information Architect — by Kristof Saelen
There are, among others, two essential roles in the User Experience (UX) definition for a website (or basically any application). The Information Architect (IA), who translates the website concept into a user-friendly interface, followed by the Designer who turns that interface into a visually appealing representation, conforming to the client’s identity. The client is often asked to give his approval on this groundwork, before the development cycle starts. (A third role in the UX definition is the one of the copywriter, which is explained by Scribelle in her article ‘(mis)understood copywriting — copy shows its true colours’).
The Information Architect
The main task for the IA is to define the layout of the website and the general interactions between and within the pages. These come in the form of simple and clear sketches that guide the Designer through his working process and give the client an indication of what to expect. The output of this exercise is a functional document – a PDF for instance – known as the blueprint of the site or more commonly called the wireframe. Popular programs used by IAs are OmniGraffle (mac), Axure RP (mac + pc), and Visio (pc).
The Designer
This is the person responsible for making the website look good by choosing the right colors, shapes, fonts, icon styles, etc. He is the next in line after the IA has done his work.
Although the roles of Information Architect and Designer can be fulfilled by one and the same person, it’s important to realize that – theoretically – their job descriptions do not overlap. The IA shouldn’t have to consider font choice, while the Designer shouldn’t have to think about the location of the navigation. In practice, however, they should work together closely to provide feedback on each other’s work and bounce ideas back and forth, without moving away from their specialty. This method allows both the IA and Designer to maximize their creativity.
The methodology
In order to minimize bottleneck situations, it’s a good idea to set up a few agreements between the two parties. There are a number of best practices that can be helpful in making the transmission from Information Architecture to Design as simple as possible.
All of the following dos and don’ts can be regarded as tips for the Information Architect, in favor of a streamlined co-op with the Designer.
Page layout
Work on a grid.
Before you start the IA exercise, it’s good to talk to the Designer and decide upon a grid structure together. A grid provides support to the definition of the layout and the alignment of objects. It can be very simple. A proven working technique is the 960 Grid System by Nathan Smith.
Separating chunks of content.
The use of vertical and horizontal lines helps you to visually separate content sections from each other.
(e.g. sidebar navigation)
Grouping chunks of content.
You can use simple rectangles (boxes) to group pieces of content that belong together.
(e.g. banner)
Boxes in boxes in boxes.
Background colors can be helpful when you are using boxes in boxes. This usually happens in complicated parts of the wireframe. By choosing different shades of grey for each level, you can indicate how boxes are nested and thus clarify the content hierarchy.
Only use boxes when needed.
Boxes are not always necessary to structure content. A lot can be achieved by proper alignment on the grid.
Fundamentals
Use notes.
Depending on the complexity of the website in question, wireframes are not always easy to understand on first sight. In difficult situations, providing an explanation of how things work is a big help to the Designer and the client.
Example: “This photo shows a description on mouse rollover”
A button is a button.
The Designer needs to be perfectly aware of what the website controls do. Therefore, it’s important that a button stays a button, a tab stays a tab, and an input field stays an input field. You can avoid confusion by choosing the right shapes and applying simple effects to your controls. A discrete drop shadow, for instance, helps a box with text to be identified as a tooltip. There are many stencils out there – serving as plug-ins for your wireframe software – that include predefined sets of controls and objects.
Make clickable items blue.
Blue is known as the ultimate color for interactive content in wireframes. It works on navigation, underlined links, buttons, icons, etc. In the design phase, it’s up to the Designer to apply a color that fits the website’s brand.
Black and white.
There is no easier way to display wireframe objects than in black and white. It works perfectly fine for elements that are not interactive (drawn lines, boxes and text etc.). Except for buttons and other clickable items, this good old tradition is the way to go. Also here, playing with colors and contrast is the job of the Designer.
Grey for greyed out.
Low contrast is usually associated with disabled or greyed out items. That confirms the importance of black on white. Grey may trigger confusion when used improperly.
Provide an indication of the fold.
It’s ideal for the Designer to know the target fold position before he gets started. Even though it may seem impossible for him to meet this constraint, he can take the use of vertical space into account to minimize the damage.
Copy
Underline hyperlinks.
Web users are familiar with underlined texts functioning as links, especially in body texts. In fact, it’s been a standard for as long as we can remember. Combined with a blue color, there can be no doubt for the Designer or the client.
Stay away from fancy fonts.
Non-standard fonts are a bad idea in a wireframe. They don’t always include the uncommon characters a website might ask for and may influence the Designer’s creativity. Arial and Helvetica are preferred fonts, as they support all characters and are highly legible. The Designer is supposed to know the character sets of the fonts he decides to use in the design. This is very important in multilingual projects.
Avoid ALL CAPS.
Designers tend to copy-paste text blocks from the wireframe directly into their designs. When titles or button texts are wireframed in uppercase, the Designer has to manually retype the entire piece in order to transform it to lowercase.
Keep font sizes real.
Unrealistic font sizes in the wireframe can cause trouble for the Designer. When too small text is fitted in the wireframe, it is unlikely to fit in a design that incorporates regular font sizes. For title and body areas, a minimum of 11 or 12 px is advised. Header texts, footer texts and small print are generally smaller and are safe starting from 10 px.
Emphasize.
Use bold or italic to mark highlights and accents. For example, when you want to separate a title from a copy block.
Since underlining is reserved for hyperlinks, it’s a no-no when it comes to emphasis.
Making lists.
Keep bullets as simple as possible, a plain circle or ball never fails. Bullets can also come in the form of icons. For example: plus signs to show a list of pros and minus signs to show a list of cons. Or check marks to show a list of benefits.
Needless lorem ipsum.
Lorem ipsum should not be used just to fill a space. The Information Architect should account for every section of lorem ipsum placed within a wireframe. The inclusion of unnecessary paragraphs of lorem ipsum just to fill up space can drastically affect the overall page design. It is advisable to obtain the final copy from the client or copywriter before the end of the IA phase whenever possible.
Reserve buffer space for text.
Clients are known to ask for copy changes up until (and even beyond) the delivery date of the project. This means that, most likely, the copy in the wireframe is not final. It may become somewhat shorter or longer.
Multilingualism: a better reason to reserve buffer space for text.
As mentioned above, you need to keep in mind that wireframe copy may not be final. But for websites that support multiple languages, it’s mandatory to foresee buffer space. Wording length can eventually increase by 50 to 100 percent when translated to other languages, such as Spanish, French or Russian. Multilingualism takes thorough determination, since it affects almost everything in a website: title space, button width, multiline navigation items and so on. Basically, anything that contains text.
Graphics
Placeholders for pictures.
Logos, photos, videos, thumbnails and illustrations that are part of the content, are not included in the wireframe. They will join the party later, during the design phase. Instead, they are represented in the form of placeholders. A placeholder is recognized as a box with an X inside (and label where appropriate).
It’s good practice to color it blue when clickable. Not including logos and photos in the wireframe reduces any premature discussions about aesthetics with the client in the IA phase.
Use contextual icons.
Well thought out icons express things better than words and work in all languages. Contextual icons can be helpful to clarify actions (e.g. a magnifying glass in a search button). Or they can be used next to a title or hyperlink to describe the content behind it (e.g. an envelope for 'email us').
There are probably a lot more principles that improve the workflow between the IA and the Designer. This is just a basic list to get started. Eventually, you can define your own.
