Part 3.
Layouts for different form factors
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:
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.
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:
Animation of the three viewport templates on the homepage.
Animation of the three viewport templates including the grid overlay on the homepage.
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:
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:
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..."
Download PDF, 420Kb
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:
Based on this, I confirmed what many authors have stressed when it comes to large monitors in casual contexts:
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.
More Projects
Highlighted Projects
Design Process