Resume
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? 

LAYOUT

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

Staggered thirds layout

SINGLE COLUMN
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

HORIZONTAL TABS
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.  

FOUR-LEAF CLOVER
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.

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

Next I switch to tablet width, predefined at 800px. 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 isn't exactly rocket science. Most of the time it's just about moving elements that were shown in a second column downwards, so the content forms a single column. Then again, there is no need for complicated layouts on this site. It's not exactly enterprise UX. Nor should it be. 


Sometimes I do 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 things apart as the viewport size gets smaller. 


3. Phone 

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

    In organizations that take mobile seriously, Product, UX and Engineering make decisions about breakpoints that apply to all projects. These decisions are 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.  


    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? (Can we say maintenance nightmare?)
      • 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?
      • 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

    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. I suspect that the remaining 5% stem from my testing process. 


    Here's my workflow: 

    RESPONSIVE DESIGN

    Animation of the three viewport templates on the homepage. 

    Animation of the three viewport templates including the grid overlay on the homepage. 

    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

    You can read more about the Investment scorecard here. 


    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..." 

    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 two examples of content that I created for the cafeteria monitor. The monitor size was 1920 by 1080 px. 

    VERY LARGE SCREENS