At my job, I’m one of two designers. My coworker is an incredibly talented designer, but comes from an agency background, and doesn’t code. We are rebooting our company’s existing app with all-new design and functionality. He’s been working on some excellent concepts for it, and we are almost ready to think about visuals.
With a small dev team in house supplemented by off-shore teams, and an immense number of sections to build, I want us to work more off of some concept screens, a style/assets guide, and modular sections that we can reuse. Detailed wireframes of every screen will be too difficult to continually update as we change our requirements constantly.
We also have to consider that many of our target users will be on non-3G enabled iPads, so mobile performance and touch affordances are key factors.
For those of you that attended AEA Austin, or probably any of the other AEAs, much of this was discussed there. Sarah Parmenter talked about UI design patterns and scratch PSDs of all the assets necessary. LukeW's excellent talk Mobile to the Future brought up touch targets, mobile speed performance, and mobile navigation patterns. Ethan Marcotte's talk on responsive design covered various ways to move content based on critical importance to the user, not just technical ease or device size. Outside of AEA, Jonathan Snook’s SMACSS is one of many great resources for how to write modular CSS, and Mark Boulton's Gridset app, Frameless, and Twitter Bootstrap are great examples of how to build responsively. (I’ve barely scratched the surface here!)
He asked me to write up a list of “best practices,” if you will, for him to base his visual style work off of. This list is a compilation of my AEA notes, articles and links I’ve saved, experience, and my ideal of what our process may be going forward.
Style Guide Guidelines
For designing responsively…
- As Samantha Warren says at Style Tiles, "Develop a design system rather than designing fixed-width pages."
- Determine a layout and navigation pattern that works for all device sizes. See LukeW's Multi-Device Layout Patterns and Brad Frost's Responsive Navigation Patterns.
For user experience…
- "Design that does not serve people does not serve business." —Jeffrey Zeldman at AEA Austin.
- Don't cut out critical content on mobile just because it's difficult to place. If you have to cut something, determine what is most crucial first. Keep in mind, we don't know what our users want to do on our app on the iPad (or any mobile device), so we should not decide for them.
- Make content available first, and navigation second. Don't waste precious screen space on superfluous items. This is especially important on mobile devices, but not bad advice for the screen, either.
- Stay away from dark patterns. See DarkPatterns.org for more information.
- Don't make the user do extra work when a computer is capable. Anticipate their needs, but don't hide anything. (Example: 3 dropdowns for day/month/year vs 1 type-in field.)
- Provide feedback immediately, particularly in form interactions. Don't wait to verify until the user submits.
- Simplify before you suppress: content, navigation, size. Consider layout an "enhancement" that is allowed to you by having a larger screen.
In the spirit of consistent experience across multiple devices…
- Give all buttons at least 45px tall touch affordances. Thumb "size" is 72px, vs finger "size" of 45-57px.* Apple's standard is 44px tall. Microsoft's is 48px. Read more about touch target sizes at LukeW's site.
- Make all link lists have touch target sizes equal to buttons, or at least an equal amount of space between them. Visually this will give us a lot of room to read the links, as well as plenty of room to click them on touch devices.
- Hover states are great, but do not work on touch devices. Come up with non-hover ways to reveal state, content, or functionality. For example, if you are subscribed, the button should be "unsubscribe," not "subscribed" with the "unsubscribe" action on hover. See Trent Walton's great post Non-Hover for recommendations.
- Base breakpoints on your content. When your screen size changes and your layout breaks, evaluate what is most important, and change based on that.
- Read, memorize, and love Performance Implications of Responsive Design by Guy Podjarny.
- Keep in mind where you might be bulking up download size with graphics, whether they are CSS gradients or large images, with more complicated interactions or content, or unoptimized code.
For readability and ease of use…
- Default browser font size is 16px; in most cases, do not go smaller. Try 18-24px for body copy: see Zeldman (24px), Trent Walton (18-24px responsively), and Jason Santa Maria (20px).
- Keep line length to 45-75 characters. Adjust font size at different screen sizes accordingly. Go up for large browsers, and down for smaller mobile devices.
- Line height should be 150% to 175% of font size.
- Use em sizing instead of pixel sizing. Remember, target / context = result.
- Be consistent and clear with language. Interaction labels should instruct the user on the action to be performed as simply as possible (e.g. "Submit" or "Save"). If done well, this will diminish the need for helper text.
- Prefer flat style and color over the gradient-heavy or skeuomorphic style. (Note: this is a choice we are making visually, not necessarily a recommendation for everyone. That said, lots of gradients and textures mean more CSS and images, which could factor in to performance.)
- In the future we may need to theme or skin our app, so work with alphatransparency rather than color variations. This also keeps color hues accurate.
- If using rounded corners, keep a consistent corner size across all objects. If it needs to be larger, go proportionally (e.g. 4px and 8px).
- Don't use complex blending modes. CSS is catching up, but can't reproduce Photoshop's blending modes.
- Create a grid that can be fluid, and base it on the content, not screen size. Think content out, not canvas in. Use percentages, not pixels. Try Frameless, Gridset, or Gridpak.
- Use a symbol font, such as Symbolset, Iconic, or Pictos for all icons. Be semantic with them if possible.
For creating a style guide…
- Create a mood board or style tile to get across visual "feel" without having to create an entire mockup.
- Yesenia Perez-Cruz from Happy Cog on design systems: "My rule is: when you have similar or related modules, use as little variation as possible. That way, when you’re designing key content modules, the differences are clearer and more purposeful."
- Check out Anna Debenham's Front-end Style Guides article and collection of style guides.
- My favorite examples are: Starbuck's Style Guide, Viget's Element Style Guide, and Mailchimp's comprehensive UI Pattern Library.
- Define modules ("markup and style patterns"). Let assets like fonts, buttons, and colors be clearly defined and simple enough to get put together based on the page's needs. Show them visually, and then create code snippets for them using with a tool like Pears.
- In a PSD, keep each asset in their own named group, and group those by type (buttons, colors, module, etc.) If your style guide is a webpage, keep each group on a page or section for easy quick access.
- Label all colors with their HEX values as well as (either) RGBa or HSLa.
- Label all buttons with their height width (in px or ems). Keep button text on a separate layer. Use web text for button text, rather than image buttons.
- Define icons and their uses. Define sizes (small, medium, large) for different locations and screen sizes. Be clear on their use.
- Create a type specimen sheet. Remember that it's better to specify fluidly in ems, so create header size proportionally to body size, rather than specific pixels. Label them in the style guide.
- Label locations or modules that type styles will be used in. For example: page header, app header, article/topic headline, meta information, body copy, body links, major and minor navigation links, sidebar header.
Hopefully this list will be of use to us as we start designing. I’ll be sure to update and let you know! We have a lot of work to find a process that fits us, and I hope this is part of it.
I’m sure I’ve missed some great resources, so if I have, please let me know so I can include them! I’d love to keep this list as comprehensive as possible. Feedback would be great, too, on the practicality of this advice, how you fit these tools into your company’s process, or anything else. Let me know on twitter!