Editor’s note: This is a chapter from Jane Portman’s new book, The UI Audit.
User interface design is an amazing industry: it originates from the 10,000 foot view of business strategy, while being a rock-solid practical craft. No wonder it intimidates everyone, especially SaaS founders. In my new book, The UI Audit, I set out to debunk the UI/UX myths about web applications—all to provide simple, actionable techniques that actually correlate with product strategy.
How do you make your web app layouts simple and focused? How do you make sure your UI correlates with the user’s important goals and tasks?
Let me show you the exact method for auditing your screen layouts. In this chapter you’ll list the key screens of your web application and run a usability checklist on each of them. You’ll learn about the 5 key components of an ideal screen and define your biggest UX challenges.
Prep work: define your product strategy
First you need to write down your product strategy. You’re welcome to download the complete free chapter and worksheets on product strategy here.
The 4 components you need to define are:
- Audience: who are your ideal users?
- Goal: what big goal do they have in mind when they sign up?
- Tasks: what tasks do they perform daily when they log into your web app?
- Objects: what items do the users handle while performing these tasks?
This product strategy will guide all your design decisions, so keep it in front of your eyes at all times.
List the key screens
Let’s list the key screens in your app. Those screens are the most important. They facilitate the tasks from your product strategy. Omit the remaining “service area” of your web app: account, settings, authentication, etc.
For the best results, work through your web app, starting from the very sign-in. Where does the user land when they log into your app daily? Where do they usually go from there? Go through all the items in your main navigation.
Now let’s run the usability checklist. The ideal screen has these 5 things done right:
- One huge title
- Obvious navigation
- One list of objects (or a single object) per screen
- One prominent task per screen
- One prominent CTA per screen
1. One big title
One of the greatest challenges for the user is to understand the context of what they see. You’d think they would remember what link they clicked on before landing here (and wouldn’t lose context), but their memory is surprisingly short. A big title will definitely help them regain their context!“Use one big title above the fold to help users regain their context.”
Somewhere above the fold—where titles usually appear—you should clearly state what the screen is about. It can either be the name of the screen itself (Dashboard, Clients, Product Details) or the name of the object you’re describing on this page (product name, client name, etc.).
2. Obvious navigation
For an individual screen, obvious navigation means that 2 things should be obvious to the user: Where am I now? and How can I go back?
Here’s what you can do to answer the first question: Where am I now?
- Include a big title (as described above)
- Make sure the current section stands out well in the navigation bar. That’s not completely exhaustive (there might be a second level of navigation that’s not visible), but it definitely helps.
- Use the breadcrumbs: they help a lot to understand where the user is, and conveniently link to all relevant sections of the app
Here’s what you can do to answer the second question: How can I go back to where I was before?
- Include Go back to… somewhere close to the top of the screen. Notice that Go back to the product list works much better than just Go back—it has an action verb and clearly states where the user came from.
- Make sure the browser Back button works in a predictable manner
3. One list of objects (or a single object) per screen
No matter what the device limitations, you can always use the vertical space generously: it’s one of the safest usability assumptions. Nevertheless, it comes with a big if—if the content is monotonous.
When a user sees a table header and a monotonous list of objects, they automatically assume it’s all there is. If you add important content or another list underneath that, it might never get discovered!
In more complex screens, you have to deal with 2 or 3 screen areas that need to be visible at once, which often becomes a challenge with smaller devices.
There are of course exceptions to the rule:
- complex software that’s used on desktop computers, where the user traditionally has a large monitor—CRM systems, graphic and engineering apps, etc. (hardly ever used “in the field”);
- Dashboard, Homescreen, Profile, or similar, which can include a sequence of list “previews” leading to actual sections of the app;
- situations where the key experience is drag-and-drop between 2 work areas;
- screens where a lot of small settings or elements are combined.
For all these exceptions, it’s a rule of thumb to include big second-level headlines.
So what should you do when your screen has more than one list, and it might be a problem? Break it down into a few simple screens. Name those screens to identify the objects shown, and try to accommodate them in your navigation (usually they fit well in the same navigation level as the original screen).
Another frequently used “hack” is to use tabs to accommodate several object lists under the same header area. In this case, make sure the header area doesn’t occupy too much vertical space. Another concern here is that tabs work poorly for narrow screens (like tablet or mobile versions).
4. One primary task per screen
Each key screen should facilitate just one primary task from your strategy worksheet. Go out of your way to super-optimize each screen for one core experience—such as browsing items, reading, watching, writing, calling clients, or anything like that.“Go out of your way to super-optimize each screen for one core experience.”
It’s your magic key to building successful software! Whenever you define that primary task, all your decisions about organizing this screen become much easier.
Imagine we’re designing a contact table for a CRM system. The primary task here would be call a lead. Ask yourself, what data is necessary for the sales agent to qualify a suitable lead and make that call? Preferably without leaving the comfort of this working environment.
Current lead status and the latest activity will help the agent to qualify the lead. The client’s name and phone number are necessary to make the call. But does their email address matter to someone making a call? Probably not—therefore, you can easily omit it.
Real usability success happens when you streamline this key task really well. Make the user’s most important workflow one click shorter, a bit more convenient, a bit more pleasant.
What should you do if you have 2 tasks per screen or more? It can definitely happen. Just pick one primary task and focus on optimizing it. Other tasks can exist, and even be taken in consideration, but that primary task should always have more influence on your decisions.
Sometimes it’s easier said than done. During client UI audits, I would stare at a single screen and be amazed at its complexity. I’d think, “How in the world can I apply my own ‘one task’ rule here?” The answer is, if you do the one list exercise first, then your one task becomes much easier to identify.
5. One prominent CTA per screen
It’s also true that each screen should have just one big call-to-action button. The human eye doesn’t like to be distracted with a variety of choices. Quite the opposite: we prefer to be guided into a single important action. There definitely can be more, but they should be more subtle.“Make the user’s most important workflow one click shorter.”
That single CTA might not be the same as the key task above! For the contact list in a CRM system, a prominent CTA button will probably be add new lead, while the important task will be call a lead.
What’s the difference? The previous one task rule above usually relates to existing list items. If you use a big CTA button for each list item to represent this task, the UI will look overwhelming. Such buttons should be subtle.
This one CTA rule, on the contrary, relates to something you can do with the list itself (add new items, export the list, etc.). Here one big CTA becomes desirable and acceptable.
There’s also a modification of this rule that you can use: one prominent CTA per screen area. This means your navigation bar can have one big CTA, while your workspace can have another—and they’ll co-exist just fine.
What should you do if you have too many CTAs that look equally important? Pick one that represents the most desirable/popular action. Make the remaining CTAs more subtle (smaller buttons or inline links).“Each screen should have just one big call-to-action button.”
Take a sheet of paper. List the key screens in your app. For each screen, answer 4 questions:
- What is the title of the screen? Is it large and bold enough?
- Is it obvious where we are? How can we go back?
- What objects are shown in this screen? Is it just one list of objects (or a single object) per screen?
- What are the tasks that the screen facilitates? Is it just one task per screen? Am I doing a great job at making this task as comfortable as possible?
- What is the primary CTA for this screen? Are any other CTAs competing for attention?
This should give you a whole new perspective on your existing software. Did you find many complications/inconsistencies in your screens? Which screens turned out to be the most challenging?
If you’re interested in optimizing UI/UX design of web applications, you’re welcome to learn more from my book, The UI Audit (free chapter and worksheets on product strategy are available).
This functional approach should help you make more educated product decisions and design simple, effective software products. I wish you good luck in your design process!
If you’re interested in optimizing UI/UX design of web applications, you’re welcome to learn more from my book, The UI Audit (free chapter and worksheets on product strategy are available). Use the promocode INVISION30 to get 30% off any book package.