Scale your web app’s profitability by using this UX audit strategy to identify quick wins that make your product easier to use and increase the impact of your solutions to their problems; which can lead to converting more free trials to paid users and plan upgrades to predictably grows your MRR.
You know your digital product needs that usability facelift, but your limited $$$ prevents you from hiring a top-notch designer to help you pin-point those bottlenecks and don’t even know what questions to ask yourself.
Your tiny business is almost that magical dream team, but you’re missing a key player: a UXer to help you conduct a solid heuristics analysis over your key pages that could pivot the angle for rapid growth and onto Y Combinator’s radar.
This guide isn’t primarily for established software companies, but it can be extremely useful for smaller teams (entrepreneurs-in-residence) within a corporate setting that are looking to build upon existing features and validate new ones before they throw big bucks at development.
Step 1: The Game Plan
Define your ideal paying client (audience, goals, tasks & objects). Go past gender & age. Include habits & tools they currently use and how they’re using them. How does your product fit as a solution to get them to the promised land?
That’s easy enough, right?
However, somewhere along the line of users navigating your web app, they start to get confused, don’t know what to do, need clarity, or there are too many options all at once. Frustrated, they leave and never come back.
Remember that smooth scene sequence in the Matrix with Morpheus turning to face Neo? It was brilliant, seamless continuity.
Part of what makes it such a great scene is that the editors were so skilled in clipping the scenes, you didn’t even notice the change of cameras. They were so great at doing their job that the audience didn’t even notice them. That’s it, that’s the secret.
The perfect experience you can offer your users is to simply get out of the way of their tasks to accomplish their goals.
Stupid question, do you want them to stay or go (aka, churn)?
So, in order for you to provide your users with the tools they need so that they don’t need you, you first need to gather intel on your potential power users.
01 Who are your target, paying users?
I’m not just asking about gender, age, and profession…I need you to think about their habits, what other products do they already use, what forums do they hang out at, what comments do they post on the blogs they follow?
Do they have the purchasing power to use your product? Do you even like them?
02 What’s a big enough goal with obstacles in the way that your web app has the solution?
Let’s talk about you and me. You want a better solution for your product’s UI/UX and I happen to be a UX guy making you that offer, because you want:
- more paying clients;
- better, paying clients
- to make more money
- more freedom and not be run by your business
- spend more time with your loved ones
- to travel more
- a nest egg for your retirement
- one day to be in an amazing position to start a fund, charity, trust, or non-profit!
Ok, the second half is in no particular order. But how much more did the first half resonate with you? My job isn’t to help you start a non-profit, but my service offering does help cultivate the big lifestyle changes related to the success of your business if I can help it.
Let me ask you again, what big obstacle is your ideal client-facing with that your digital product can help solve and what sequence of bigger and more important goals does it help them align with?
03 What are they repetitively doing and using on a daily basis when they’re logged in?
Set critical thinking aside and simply list out the steps in the sequence of tasks they perform to accomplish their tasks.
Let’s answer this question with commuting to work: do walk, take your bike, or use your car?
- Use your keys to open the car
- Get in
- Check your mirrors
- Adjust your seat
- Put your seatbelt on
- Turn on the engine
- Put your favorite music on
- Look for oncoming traffic
- Shift gears
- Pull out…
We haven’t even gotten to the part of where your office is at, yet we’ve been able to list the necessary tasks at a granular level of what needs to be done.
But we know enough of what that repetitive tasks are and what objects are being used to get it done.
So now, answer me these:
- Who is your ideal, paying customer?
- What’s an obstacle you have the solution to and what will it help them achieve?
- What do they do and what do they use to do it?
If you can answer those three questions, you’ve laid the groundwork for your game plan, your strategy.
Step 2: User Journeys
Your objectives are to provide easy instructions for your users to navigate your application. Avoid clever titles and obscure language. Lists are nouns, buttons are verbs and longer explanations should be hidden (though accessible via tooltips).
Don’t nest your navigation deeper than three levels, it just means that you need to re-categorize them.
Can I tell you one of my biggest pet peeves with ANY type of web designer?
CLEVER NAVIGATION TITLES
OMFG does this make me click away at best and make me binge the Office (US version) just so I can yell at Michael Scott.
Listen, creative & pragmatic decision-making in web design & development go hand-in-hand. But FFS not when I’m trying to look for pages, files, resources, assets or a g’damn CONTACT support link!
Establishing proper user journey design patterns is all about saying it succinctly. Get to the point and get me there fast!
Creatively clever headlines & labels are the loose arrow signs in Alice & Wonderland that could send your users anywhere (including away from your application) except where they need to be.
Drill this list into your strategy:
- K.I.S.S. – Keep It Simple, Stupid. Don’t go on fixing things that aren’t broken;
- Don’t nest your navigation too many levels deep, this isn’t Inception;
- Avoid hover states whenever possible…in fact, if you can do it without pseudo-classes that aren’t touch screen friendly, DO IT;
- Depending on the complexity of the task and if appropriate, make it mobile-friendly.
Inform the user what the anticipated click action will do before it’s actually clicked.
Optimize your click actions around specific tasks at the first line of defense: top-of-navigation or first touch-point.
If you’re having a hard time figuring out where your users are facing bottlenecks, go to your click-through heat map (you DO have one installed, right?) and refer to your most requested support inquiries. What do they keep looking for that makes them give up, but miraculously still stick around to ask you?
Communicating with clarity is key to completing smooth user journey experiences. Use the same EXACT language for elements that are doing the same EXACT tasks. Speak in their tone and be consistent. Is it “Hello”, “Contact”, “Support”, “Help”, or “SOS”?
How savvy are your users? Are they techies themselves or at the ugly bureaucratic end of HR? Top-level navigation sections are precious real estate. Don’t let it go to waste with mundane, standard features like “Settings”.
Group your elements with related tasks. When push comes to shove, grouping 5 – 8 item lists is much easier on the eyes than a long-ass navigation list across the top that pushes the block element to the second row, crowding onto each other.
Lists are nouns. Buttons are verbs.
Do put icons next to labels to reinforce organization, but avoid icons without labels, unless it’s a watertight meaning that trash cans are to remove elements & plus icons are to add them.
Ask yourself this: if you had a given route on Google Maps and you grabbed the little yellow guy and dropped him ANYWHERE along the path, does your interface have enough information to orient the user and get him back on track to reach his destination?
Step 3: The Dashboard
Decide what type of user and at what touchpoint in their journey s/he is accessing your web app.
Only provide relevant information or remove clickthrough steps to get to the information, faster.
The dashboard isn’t a work environment, nor the primary access point to your user’s tasks, but a facilitator for viewing systems’ status and accessibility.
Let’s step outside the scope of nerdy talk and talk about houses, apartments, condos, townhomes, etc…
Different styles are meant to evoke immediate feelings & actions under the umbrella of hospitality, warmth, excitement, and a sense of belonging.
The moment you enter through the front door, what do you see? Chances are that your first step into a foyer, followed by a living room, then dining room, and possibly a kitchen.
How is this possibly different from a penthouse suite? What is the priority here? How is it this space’s priorities similar or more likely, different from a college dorm and public housing in section 8 (the projects, for non-US readers)?
Your users have logged in, now what?
Before you decide where to send your users, you must decide what type of user they are. At its most basic, are they an administrator or primary user? Secondly, are they new or returning users?
A dashboard and a home page aren’t the same things because their purposes lie explicitly with their visitor. I’ve been speaking at length of simplifying systems, elements, and patterns.
Houses don’t particularly have two front doors, why would you feel the need to have both? Perhaps, and the likely scenario, you need to rename & re-position your idea of a home page screen. Is it closer to “user profile”, “settings”, or another set of instructions closer to administrative tasks?
Do Lead with a Dashboard, if:
- The user requires metrics of system operations (i.e. databases, API hook calls, polls, reports, feedback, tests) that are paramount to the visibility of system status and keep the user informed throughout for reassurance or alert of necessary action;
Don’t Lead with a Dashboard, if:
- The user consistently goes to a specific screen view of your web app that requires more clickthroughs to get to their desired destination. Just go ahead and do it for them.
- Provide information relevant to the user role. Administrators shouldn’t see the exact screen elements as the primary users;
- Form follows function. No glamor & glitz, get them the information first;
- Group related elements in a way that the user can navigate to different areas of your web app easily;
- Give your metrics a human context. Is the label “System Operations Satisfactory” a way you’d want to let your users know their system is up & running? What is a better, simpler, more bitesize, ways to say it?
- Use a small color swatch and stick to it;
- Neutral background
- The primary color is for important call-to-actions
- Secondary color for less important, but necessary actions
- Standard text color.
- If you think you need more colors, think about other aspects of visual hierarchy to convey information: size, font weight, background elements, images, square vs circle bullets for lists…;
Step 4: Key Screens
Write down ALL screens accessible to the user. Cross out administrative & user settings views.
Which screens command both proactive and reactive reactions?
Run through them and identify the following:
- Clear navigation
- Primary call-to-action
Which screens offer clarity over their role to user benefits and which need more investigation?
Do me a favor and go back to your answers from Day 01: The Game Plan. Read it over as a refresher to keep the prize in the back of your mind as you go through your web app screens.
Write down ALL of your screens viewable to the end-user. Cross out administrative & user settings views for this exercise. We can fine-tune those later.
Map the Design Patterns
With pencil and paper, as you’re going through your screens, draw them out as a wireframe to visualize the conditional logic of different design patterns the user can create.
When you have your to-do list visualized, now we can run our UX audit.
- The Title
- Clear Navigation
- Primary Calls-to-Action
01 The Title
Let the user know where s/he is right away. Nothing clever, nothing fancy. Straight talk. Give the user context of what they’re looking at and where along their path they’re at.
Recall the earlier exercise of distinguishing terms such as ‘Dashboard’ and ‘Home Page’ or ‘Contact’ and ’Support’.
Is your main audience reading Latin characters? Then it’s likely that they’re used to seeing important information left-to-right and top-to-bottom. Don’t give them the chance to guess.
02 Clear Navigation
This part should be easy since we’ve already talked about it. How much information is enough information for your user to know where they are in your web app?
Horizontal VS Vertical Navigation
Horizontal navigation is helpful because they’re usually located where our eyes are trained to see first on a web browser. Breadcrumbs can be included to give sub-pages context of how far into the rabbit hole a user is, without actually feeling lost. Bonus tip: make the breadcrumbs active links to allow user to skip steps without going through unnecessary doors to get to their destination.
Vertical navigation is super helpful when you have many objects to group and categorize without crowding the top bar. Collapsible trees make it easy for users to understand the context of those objects and their organization.
However, you decide to guide your users, remember that context is key. What’s more useful for a user that was paying for add-on plugins on your system and forgot one other plugin…a ‘back’ button or ‘return to plugins list’ button? 😉
03 Primary Calls-to-Action
As you’re quite familiar with landing pages, their main objective is some type of conversion. Whether it’s to fill out a form, make a payment, schedule a call, or up/download content, there’s an expected action from the user to complete that pattern.
On web apps, your CTA is centered around the context of the objects currently available to your user. Your objective is to present content in such a way that makes it easier for your users to complete the action with decisive resolution.
To make this easier, start with the end in mind. What do you need to happen? Let’s say you want to qualify a potential lead to get on the phone with your sales department.
Now that the keyword is “qualify” because you don’t want just anyone using up your sales resources if the caller has no purchasing power, you need to ask yourself what qualifications need to be present to evaluate the lead.
When you’ve decided on those metrics, how are you presenting them?
Think of the nature of those elements: labels, input fields, radio vs checkbox buttons…what group of objects create an ecosystem where that ONE CALL-TO-ACTION (qualified leads) can thrive?
Finally, run that simulation again, but in the proper order and look for gaps that hint at even the smallest chance for your user to lose focus and decide if more information is needed or you need to remove elements to reduce confusion.
There will be many instances when two major actions can take place, such as restaurant POS software or big data tables. But don’t just throw your users to the wolves.
Remember, context is key! Your software is a live organism in a digital ecosystem. What needs to happen right now vs what needs to happen tomorrow vs next week?
The context will help you simplify and tighten your focus, no matter the complexity (waaaaaaaaAAAAAAAaaaaaay easier said than done, I know).
- Read over your game plan strategy
- List your key screens
- Run the steps and see which ones make the cut, and which need further investigation
- Are they aligning with your game plan strategy?
- Are you making the application as easy to use as possible?
- And finally, do those CTAs fulfill your software’s promise to your users?
Step 5: Good-Enough UI
Want to avoid the most common design pattern fails? Get a theme.
Remove, remove, remove, and remove some more elements. Let your application breathe.
- One font, three weights
- Up to three colors: primary, accent, body
- 1 icon library
- NO GRADIENTS
What is the minimal amount of information you can present without overwhelming the tasks or the decisions the user needs to take?
I’m not saying your digital product’s home should be empty, but you’re at the beginning. Features should come gradually where “bells & whistle” features should come ONLY after your basic user needs have been met.
Think back to the penthouse suite example where you only want a house.
Take a moment and browse splash pages on behance[dot]net and dribbble[dot]com to be on the lookout for modern and minimalist design.
Look at how they present and group elements.
Now go back to your apps UI: limit yourself.
I’ll just go ahead and give you the recipe:
- 1 font-weight for headlines (no bigger than 42px) or body (no smaller than 14px) copy, but not both, avoid light weights for phrases longer than five words;
- 1 font-weight for headlines or body copy, but not both;
- 1 primary color that is your main call-to-action (also should be your text link color), but don’t overuse it, remember if the user has to remember one thing, it should be in this color;
- 1 secondary color that is for less urgent actions, but still important. Keep it on a muted tone against your primary color because it could also be used for your icon elements;
- 1 body copy color with high contrast against a white background, preferably black;
- 1 icons library that doesn’t compete with other visual and elements and signals;
- Don’t you dare let your UI become a rainbow, but do allow contrast in tints and shades between your initial color palette.
- NO GRADIENTS
Use Google Fonts for font selection and even let it help you pair your sans VS serif combination.
Use coolors.co for color palette selections and explore swatches other users have uploaded.
Use Material Design Color Tool to preview your color swatch combinations and trust Google to make the contrasting hues VS tints combinations for your UI elements.
Use Accessible Colors to make sure that your text is legible in size and color against its backgrounds. Great tool for text alerts.
But, what you’re REALLY after is to get a theme THAT WORKS!
And that’s exactly what I’m working on right now (due November 26, 2019). It’s a mid-high fidelity Sketch UI kit.
Plan of (in)Action
At this point, you’ve defined your strategy & goals, audited your key screens, and have a bundle of resource links to get it done.
There are three options for you to take:
- Do nothing – there’s nothing wrong with this option. You’ve discovered a laundry list of improvements that can be done to your product but say you’re brand new to the market and the launch date is around the corner. It’s much more important to get your solution out there and in the real world than investing your shoestring budget into UX improvements and fiddle with hypothetical suggestions. My advice, do nothing, launch your product, get real user feedback, and match it against your discoveries and fine-tune feature improvements for future releases;
- Baby steps – this is my best recommendation. SaaS products are live & dynamic specimens. They’re not like working with logos which are meant to last as much as possible. SaaS software is a journey. And from these hypotheticals, it’s difficult to document what is working and what isn’t when you don’t have extensive resources and a dedicated analytics team if you’re making many changes all at once. So, look at your list and prioritize that ONE task that is pivotal to reducing the barrier of usability for your power users to complete a single task;
- UI overhaul – whether you have the money or not, you shouldn’t invest resources in reinventing the wheel. There are way too many great solutions of low-cost themes & templates on UI elements (such as dashboards) for you to redesign it from the ground, up. I’m not trying to be sneaky about it, but Envato’s Theme Forest marketplace truly is a great start for you to get a low-cost theme and customize to your needs.
However you decide to release your changes, they should be discreet in presence and look like they’ve always belonged there. We don’t want to disrupt user habits and create more friction between them and tasks we want them to accomplish.
Remember what I just said about SaaS being alive; your users want to know that their product is always striving to improve.
Look at how WordPress always has a list of changes and upgrades they’ve made each time they have a new major version.
While there’s a lot of truth that YOU are not the user and should actually run test scenarios with as many power users as you can, this exercise can allow you to clean up quick wins before approaching them.
If you still think that your web app could benefit from a UXer that basically is all he does, click below and check out my UX Audit teardown service.
Did I miss anything or not explained a step enough? Comment below.