If you’ve worked in software development for a while, you may have noticed that work to address poor usability gets postponed more often than work on new features and functions. But this need not be an either/or proposition.
Postponed usability work – whether it’s identified by your customers or your user researcher – can be seen as a form of tech debt. It typically accumulates with every release.
What contributes to this accumulation?
- Poor timing or process. Some usability issues aren’t identified until after the product is released.
- Pressure to get to market. There’s often pressure to leap ahead or catch up with competitors by adding new features and functions immediately.
- Perceived relative value. If multiple teams compete for a share of development resources, a new feature may attract more funding than tech debt.
There is a path to a more usable product, at a low-to-moderate cost and with low-to-moderate risk. With every release, take some of the following actions.
Have one developer or one content resource spend one day to:
- rewrite error messages to be clear.
- replace jargon with plain language in the user interface.
- fix outdated information architecture.
- prevent user errors — both slips and mistakes by refactoring released code.
- shorten or reduce complex workflows.
These are listed roughly from lowest-cost/lowest-risk to higher-cost/higher-risk. Even the last one—changing workflows—can be safe and affordable, as shown by a case study. Of course, you’ll also subject any changes to your Quality Assurance process.
Here are some details about each above suggestion.
Rewrite error messages to be clear
Web usability consultant and human-computer interaction researcher, Jakob Nielsen, proposed a list of 10 heuristics. These broad rules for usable software ask for visibility of the system status. When there’s an error, “help users recognize, diagnose, and recover from errors,” and adds that “error messages should be expressed in plain language, precisely indicate the problem, and constructively suggest a solution.”
Rewriting error messages is low-cost and low-risk.
Replace jargon with plain language
If usability testing shows that some groups of customers or users can’t make sense of the text in your user interface, fix it.
Jargon is useful as shorthand that lets professionals communicate precisely and quickly. But when your intended audience includes novices, or non-professionals, it’s better to replace it with plain language.
And even experts benefit from plain language.
These changes tend to be low-cost and low-risk to implement, with substantial improvements in comprehension.
Fix outdated information architecture
As a team develops more functions, it gets harder to shoehorn them into the software in a way that makes sense to users. The information architecture, or IA, that worked for a smaller set of functions becomes unclear. This also applies to a website as more topics and tasks are added.
IA research is relatively easy and low-cost to conduct. For example, I worked on a software package that had many menus and commands. We added a logger and then analysed which commands were used together, and which were used in succession. We wanted this data so we could redesign the menus and toolbars that were organised to match how users worked. And first-click testing meant we could confirm that the high-level IA would work.
With the help of a user researcher, IA studies on possible ways to organise websites are even easier and faster to do—an important step when adding new elements and new areas of content to a website or service. Tree testing and reverse tree-testing (or card-sorting) are the standard methods for this.
Running an information-architecture study has a moderate cost. Updating labels and re-organising a user interface is usually low risk and low cost, depending onthe scope. To limit costs, do this work in small bits, where it makes sense.
Prevent user errors—both slips and mistakes
As you design and build functions, prevent what are likely to be common problems for users. If you’re not sure what those might be, ask your user researcher to find out. Then refactor the code to
- remove error-prone conditions, or
- prevent error-prone conditions by adding input constraints, or
- detect the error-prone state—and then ask the user to confirm what they want, or suggest alternatives,
and to
- design the feature to be flexible, without stopping the user in their tracks, so the error to be fixed later.
Before coding begins, encourage your user-experience designer to work with the development team to identify and address possible errors. The risk of this work is rolled into the risk of building the feature. The cost of writing code to prevent errors is low to moderate at the time the feature is built, higher if fixed later.
Shorten or reduce complex workflows
Complexity hurts user performance, and increase the need for training and user support.
Fixing complexity may be cheaper than you think. For example, I redesigned the user interface of a data-entry task, without a single change to the back-end code or database architecture. This reduced the cost and the risk of the code changes.
After we built the redesigned user interface, user research showed that it reduced task time by 60%, data-entry errors, and the need for training. You can read about it in detail in this post about mental models.
Expand your scope
As a usability practitioner, interface designer, or user researcher, there may be more activities you can do in the course of your work, to add value:
Design and define the product to be usable
At the design stage, advocate for users. Provide data about known issues, existing defects, and topics that result in more support calls. Support a design that doesn’t repeat existing, poor design patterns for the sake of consistency.
At the design stage, write requirements in Agile stories so the new product follows published standards and guidelines, such as the Design for Windows apps, Human Interface Guidelines for Apple apps, and heuristic evaluation. Ask the project’s business analyst to give you input into the usability requirements they write for the development work.
Writing requirements is low risk and low cost if done before the work is estimated.
Review the design to ensure it prevents errors user errors—both slips and mistakes—and shortens or reduces complex workflows.
Reviewing the work and advcating for revisions has a moderate cost—but is less costly than building an unusable product that must either be redone later, or that is never redone and so never perfoms as it might have, in the market.
Plan to usability-test earlier
If poor timing prevents you from identifying usability defects until after release, look at your processes.
Before development coding begins, you can test with paper prototypes or interactive mock-ups.
While development is under way, you can test with unfinished code. Ask the development manager to support earlier testing, using an early version of the code that runs in a development environment, with hard-coded data and (likely) limited functions.
Identify which functions are risky, and ask the development manager to have those built first, and made available for testing.
If you find usability defects early enough, you may be able to have them fixed as part of upcoming work, or stories, already scheduled.
Usability testing is low-risk and has a moderate cost.