Resume in PDF format, 1.7 Mb
LinkedIn

Lead Product Designer

Part 3. 

Layouts for different form factors

Top-Down Design Process

Layouts differ depending on a number of factors. Here are some examples.
App usage
  • How often is it used? 
  • In what physical, geographical or social context? 
  • How serious is it if the user makes a mistake?


Devices features and limitations
  • Viewport changes, e.g. orientation, pinch and zoom 
  • Location data
  • Bio data for one or several users
  • Recently visited sites, accessed documents or keyword searches


Intended audience
  • What do they know about the subject matter? 
  • How comfortable are they with the device?
  • Do they need to be reminded or motivated to use the app? 

Layouts

Several Layouts
I usually explore several different layouts before I decide on one. Here's an example from the Investment Scorecard.

SINGLE COLUMN

HORIZONTAL TABS

FOUR-LEAF CLOVER

Staggered thirds layout

This is the layout we went with in the end. While it means most of the content is below the fold, it has other advantages:


  • Big, bold shapes and plenty of whitespace limit cognitive overload 
  • Once the user starts to scroll, all the information is discoverable
  • It's easy to surface the most important information with a clear information hierarchy
  • Easy to design responsively

I'm not a big fan of tabs. They often hide important content. It's only when the content in the default tab really is much more important than the other tabs, that I seriously suggest it.  

This layout feels static and dated now, but it is one way of getting most of the information above the fold. Today I would probably have gone for a layout of staggered thirds instead.

In my notes from the time, I was concerned about information overload. Staggered thirds wouldn't help with that.

Seeing that I just brought it up, let's tackle responsive design next. 


This site, my portfolio site, is responsive. The host, PixelTogether, is template driven. It offers three viewport sizes, desktop, tablet and mobile. According to the stats, 95% of my visitors see the site on a desktop.


Here's my workflow: 


1. Desktop

Create the page at full desktop width, predefined at 1200 pixels. When at least 95% of your users see the site on a desktop, mobile first would feel a bit dogmatic. I'm all about the realism. 


To keep my designs neat, I use a grid extension with 16 columns for this width. That gives me a lot of flexibility in terms of laying out columns. But I like to stick to 2 columns at the most. 


The work takes place on a laptop, so it's easy to test as I go along. 


2. Tablet

Given that the tablet portion of my viewership is a rounding error, you'd think I wouldn't bother with tablets at all. But experience has shown me that a desktop/phone workflow leads to lots of extra work. So for my portfolio site, I adjust the table template after the desktop template. I'm happy to adapt to whatever workflow works best for your app or site. 


PixelTogether defines tablets to be 800px wide. For this width, I've chosen a grid with only 8 columns, to encourage simpler layouts. I test in a skinny browser window as I go along. 


Rejigging the design of this site so it works in a smaller formt factor is easy. I start by moving elements that were shown in a second column downwards, so the content forms a single column. Then I adjust font sizes and padding amounts. 


Sometimes I discover issues at the tablet width that I have to go back and fix in the desktop version. Usually it's because I didn't make the desktop layout modular enough. That makes it hard to break page elements apart as the viewport size gets smaller. 


3. Mobile 

The third and final viewport size is 400px. My grid at this size has 6 columns. Most of the time I've solved any modularity issues on the tablet level, so there is rarely any need to go back up to the desktop. Some times I suppress less important elements at this size to avoid cluttering up the interface.   


4. Device test

Finally I test on various phones and tablets in portrait and landscape format to make sure the page works flawlessly.    


Generalized responsive design workflow

Generally speaking when I'm brought into an organization, Design Ops already have breakpoints defined that apply to all projects. My job boils down to reinforcing to more junior designers that we shouldn't be reinventing the wheel. If we have a specific use case, I'm happy to bring it up to Design Ops, provided that we have statistics to back it up. 


For example recently I was able to influence Design Ops to increase the overall font size for a specific device. We got complaints from older end users about not being able to read body copy, so I had data to back me up. 

RESPONSIVE DESIGN

Animation of the three viewport templates on the homepage. 

Device type analytics for this site

INVESTMENT SCORECARD BREAKPOINTS

Max breakpoint
Depending on the device ecosystem, you'll need to define one or more breakpoints. 

Just as you define the smallest viewport you'll support, you need to define the largest. Beyond that breakpoint, the content only gets proportionally larger. 


There may also be specific use cases for XL screens. They're often only seen from afar, so a landscape tablet or even landscape phone layout may be better for them. 

460px width

The next breakpoint occurs at 460px. At this size:

  • The fund score header no longer stretches across the entire width of the viewport
  • The historical performance graph becomes visible to the right of the fund score
  • This view would look better if the fund score box and Historical Performance button didn't touch the left side of the viewport. 

You can read more about the Investment scorecard here. 


320px width

320px width was a common smallest breakpoint for responsive designs because early iPhones were that width. 

 

The Investment Scorecard shown here has the following adaptations at this width:

  1. The name of the fund is truncated
  2. The menu items in the blue bar are icons only
  3. The fund score header stretches across the entire width of the viewport
  4. The historical performance graph is not visible
  5. The historical performande button has fallen below the fund score box.  


There are a number of compromises here that I'm not entirely happy with. The one that has the most impact is probably the truncation of the fund name. There are a lot of funds that have identical names, save for the last 2-3 letters. As Kristina Halvorson likes to say, 'Truncation is not a content stra...' Showing the beginning of the name and the last four letters would be better. 

In a previous job I was responsible for creating and adapting content for a large monitor in the company break room.  of the three viewport templates on the homepage. 

Above are a two examples of content that I created for the cafeteria monitor. The monitor size was 1920 by 1080 px. 


I tried collecting feedback through formal means but got very poor response rates. So I went informal instead and collected feedback by paying attention to which content:

    • got people to stop and watch the TV for a while
    • coworkers referenced in general conversation
    • I got direct feedback on
    • appeared to have an impact in other ways, e.g. funding for projects (yes, really!)


Based on this, I confirmed what many authors have stressed when it comes to large monitors in casual contexts:

    • One message per screen
    • Keep layouts simple and obvious
    • More and shorter features are more effective than fewer and longer
    • Don't assume that people will have seen preceding content


Add contextual information

To that I would add that contextual information is surprisingly important. If I forgot to put the source or date on a feature, I would often be approached by people asking about them. For example if I recorded a video clip of a working prototype, people wanted to know if the functionality shown was available on the live site. 

Very Large Screens