Lead Product Designer

Cecilia Huster

Top down design process

Part 3. 

Layouts for different form factors

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.  

Staggered thirds layout

This layout feels kind of static and dated, 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 overwhelm. Staggered thirds wouldn't help with that.

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? 

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


Investment Scorecard Breakpoints

Adaptive designs
The difference between adaptive and responsive designs is that adaptive ones are a lot less flexible. They determine what kind of device is being used and can be radically different depending on that. With the proliferation of device sizes these days, adaptive design is rare. It really only make sense when the organization provides the hardware. Tablets used by delivery personnel in a logistics company, is a common example. Another example are medical diagnostic devices, like these from Hologic.

Max breakpoint
Just as you define the smallest viewport you'll support, you need to define the largest. If you specify it as 100%, it's not going to be very usable on very large screens. Those tend to be seen from afar, so it's usually better to keep the layout the same and just let the individual elements take up more space. That's as opposed to floating up more and more elements to the right as the screen gets wider. 

Native apps

The two dominant mobile operating systems are Google's Android and Apple's iOS. 

Starting with Android, there is a bewildering number of form factors and device capabilities. There's also the well-known problem with lagging updates of the operating system. 

iOS doesn't have quite the same issues. Still, as of writing this in February 2018, there are 4 iPad and 3 iPhone sizes you can buy in the Apple store. To that you need to add, at a bare minimum, all previous iPad and iPhone generations that are capable of running iOS 11. 

It's tempting to only develop for one major iOS version, but I'd consult the statistics for the relevant audience before making that call. People who work in high-tech and/or live in Silicon Valley are likely to have a pretty skewed view of technology adoption in the rest of the US, not to mention the rest of the world. 

All this means that native app layouts need to be responsive, just like web sites. You need to know what your audience is using, so you can test with that. Being a native app designer also means that you have to keep on top of new hardware releases and operating system versions and their adoption rates. 

460px width

The next breakpoint occus 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

320px width

320px width is 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..." 

 If there is no existing policy to lean on, I start with research. This time it's quantitative:

    • What viewport size is the most common in the target audience?
    • What size is the second, third etc most common?
    • Are there traps here, e.g. low mobile usage because the site is unusable in that form factor?

Given the data, the product manager, engineering lead and I come to a decision about the number and placement of breakpoints. I would argue that in most cases fewer breakpoints are better. More important than the number of breakpoints, is that the user is in charge of how they see your content. That means not disabling pinch and zoom, accessibility selections, orientation locks etc. 

I then start designing for the most common form factor. The engineering lead and I decide if I should sketch the layouts for different sizes as I go along, or leave it till the end.

My designs tend to have a strong information hierarchy, so often what the developers have done just needs to be refined. That's best done together. If any documentation of the decisions is needed, we take screenshots as we go along.

For responsiveness the design decisions boil down to:
    • Are there any crucial elements that need to be redesigned for different viewport sizes?
    • Which design elements float up as the viewport gets wider?
    • Which elements get banished to the bottom when it gets smaller?
    • Font size, margin and line length adjustments to ensure readability
    • Image cropping so that the salient part is visible at all sizes
    • Are there elements that are less important that we can remove completely at smaller sizes?
    • Conversely are there extra elements that only show up in larger viewports?

Seeing that I just brought up responsive design, let's tackle non-desktop form factors next.

Responsive design

Responsive designs are relatively simple. In many cases, Product, UX and Engineering make a decision about breakpoints that apply to all projects. This decision is revisited a couple of times per year. There may also be ad-hoc additions if a new form factor surges onto the market, e.g. the recent iPhone X with its "interesting" notch at the top.  


Adapting content to very large screens has its own process. In a previous job I was responsible for creating and adapting content for a large monitor in the company break room. 

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. 

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