Image may be NSFW.
Clik here to view.
On the last few responsive websites we’ve worked on at mStoner, we’ve encouraged decision-making about typography at different points in different projects. This hasn’t been a failing of process, but an embracing of flexibility to meet project and client needs.
We work with a wide range of educational institutions – from Ivy League universities to private high schools. Some projects begin with a well-defined typographic system, and others need a complete typographic makeover. Because situations and needs differ, we’ve found that it’s not enough to use the same process over and over. In response, we’ve ditched a dogmatic approach to workflow and old techniques (pixel perfect finishing, traditional wireframes, and working on only one view in Photoshop) and started tailoring our process and work for each client. This shift has allowed us to place the focus on typography no matter where an individual client is starting from. Here’s a bit about what we’ve tried and what we’ve learned along the way.
Centering design presentations on typography
Five years ago, before the days of RWD, we used to show three different homepage concepts to every client. We still find value in showing a spectrum of choices to some clients, but others prefer to participate in the design process. We discovered that the same three-polished-concepts scenario isn’t the right fit for clients who want to be hands-on. In other words, “more finished” doesn’t help if “more collaboration” is what the client needs.
As a result, we’ve developed our own version of style tiles for clients who want to participate in design decisions. Our format is similar to Samantha Warren’s original, but shows more of the typographic treatments we propose for the site.
Clik here to view.
Our blend of style tiles show type first in order to help focus design discussions on typography
When we recently used style tiles for a project with Northwestern University, we asked them to evaluate three fonts for use in their design. Each was chosen for a specific purpose:
- Proxima Nova Regular for a majority of the content and to deliver an optimal reading experience;
- Proxima Nova Semibold for headlines and subheads to create a visual hierarchy and easily scannable reference points throughout the site; and
- Goudy Old Style, used only in the university seal.
The use of our type-heavy style tiles kept discussion focused on the typography rather than on finishes and details, meant the client got to help make the decisions about the most important building block of their site, and reduced the risk of us producing something we’d have to change later.
Beyond the wireframe: iterating to better type
Our clients’ sites are very large and often have more than 2,000 pages and 20 content editors. To design for this kind of scale, we typically plan them using some kind of prototype. On our first couple of responsive projects in 2011, we noticed that the traditional wireframe didn’t really work anymore (even if it started with a mobile-first wireframe) because unless a layout was a single-column across all media queries, we needed multiple layouts to describe different screen widths. The question then became: What should we show clients in lieu of static wireframes? We began trying different methods on different projects.
Block it out
For Webster University, we used simple block prototypes built in HTML and CSS to help define where design elements would go. These served as a way to get approval from the client about the stacking order of content at different views and as a set of instructions for our developers to work from.
Clik here to view.
Responsive block prototypes didn’t show enough real content – or real typography
We thought that showing less earlier would allow us to focus on content order, and it did, to a degree. But because we didn’t use real content, it was misleading. It was too neat and, therefore, too far removed from messy, imperfect reality. For example, all headings fit to one line and the quantity of paragraph text was identical and symmetrical. We couldn’t see where things got tricky and the design really broke. We also didn’t show real typography, and that meant decisions about font weight and size had to be introduced later.
In the end, block prototypes helped clarify, but because they were so basic we had to defer many of the nuanced layout decisions (for example, how the position of a caption changes based on the available width) until later in the build. If we use these again, we’ll use real web fonts and more-finished text.
Straight to the browser
For Drake University, we developed HTML iteratively in the browser using Foundation. With this method, we essentially skipped responsive prototypes and went straight into production development after showing a few initial comps – less planning, more code.
On our team, designer and developer are still separate roles (though we expect designers to be able to do a bit of development), and working in this way meant we reached a better final product by allowing both to have some decision-making in how the views adjusted for different viewports. We spent less time on prototypes that would eventually be thrown away and more time on improving the different pages of the site at different breakpoints. We were also able to plug more time into thinking about how the type would display on devices, especially smartphone displays where screen size is very limited. The developers on our team preferred this approach because it allowed for more collaborative thinking.
Sometimes the best prototype is the fastest one
For responsive retrofit projects where a desktop-only site needs to be converted to work responsively (such as the one we’re working on for NCA&T), we’ve used UXpin – an in-browser, responsive design prototyping and testing tool.
Clik here to view.
UXpin is fast and useful for showing clients how content and navigation of existing desktop sites will look and work at different breakpoints
For projects like these, (particularly when the existing CSS must be retained) the primary challenge isn’t rethinking the brand or style choices, it’s thinking critically about different layouts that use similar elements of style. The reason we like UXpin for retrofits is speed. It lets us create multiple views for tablet and mobile breakpoints much faster than by diving straight into HTML edits. We used it as a way to get approval on how content would stack and to demo how an off-canvas navigation pattern would work at narrower views.
To focus the client’s attention on the typography and layout choices, we built the NCA&T prototypes in black and white. It helped keep discussions and decisions on legibility and positioning.
Designing type for low bandwidth connections
Web performance techniques and page weight may not be something your clients are thinking about – that’s been our experience in many cases. But making the page as light as you can is still the right way to design responsibly.
The reality of how fast responsive design is changing as a practice meant our first few responsive sites were bigger than they needed to be. This isn’t just true for mStoner – Guy Podjarny recently tested more than 450 of the responsive sites on mediaqueri.es and found 72% deployed the same size page to large screens and small screens, with an average page weight of over 1 MB. This stat is most relevant when thinking about mobile connections. Slower mobile networks and latency significantly slow down a smartphone’s ability to download and display a page. Downloading assets (which includes unnecessary fonts) slows down a visitor’s ability to access a page quickly.
Clik here to view.
With Webster University, we limited the font choices to three in order to keep the font file size light
If you think visitors will simply wait for content, you’re wrong. Page weight has a linear impact on nearly all measurable outcomes of a site – a study by Amazon showed that every 100 ms of reduced load time increased sales by 1%. This is a very good argument for why you should be thinking performance when making decisions about type.
To help keep our pages light, we now select typography with three rules of thumb in mind:
- Minimize the number of different fonts and weights used in any given page. You don’t need to be a web performance expert to count.
- Use font size and color to establish visual hierarchy without adding page weight. It can be just as effective at creating typographic contrast.
- Have a Plan B for type on mobile devices if you are using multiple fonts. Backup plans can include caching techniques or only loading custom fonts for larger screens. These can help you serve content quickly over lower bandwidth/higher latency mobile networks.
These processes we’ve tried are only a sample, and the details are probably less important than where we are philosophically. We now have a strong preference for tools that allow us to use real web typography (as opposed to graphic renderings such as .gif or .png), reduce the time spent on line-by-line coding, and allow participation from team members with multiple levels of coding skill.
I encourage you to stay fluid, try new things, and ask your clients to focus on the part of your design that matters most: the typography.
A big thank you to our guest author Doug Gapinksi for writing today’s post. For more from him, check out mStoner’s blog, his tweets and his Dribbbles.
Guest authors are paid for their contribution, and all opinions are their own. If you’d like to write for the Typecast blog, get in touch with shelly dot wilson at typecast dot com