Introduction
Most designers and engineers love a challenging problem.
By solving problems through mastery of complex ideas and technology we impose control on our universe.
But over time the mastery of terms and engineering concepts takes us further and further from being able to communicate effectively with business people that have a more cursory grasp of design issues.
This essay started on a napkin as a discussion on how to calculate real costs of useablity problems
for a large corporation, and has been repeated many times since then - it usually results in an interesting conversation about funding!
Estimating Soft Costs with Many Users
Many companies find it difficult to justify spending on soft costs. It's just business. But it's easier than you'd think to quantify the real costs of small frictions in our everyday tasks - what we need to do is convert time to money using a pro-forma business method.
We can begin with a usefully large number of people affected. This can be the number of employees for internal processes (or potential visitors for eCommerce sites). If we use 8,000 as a starting point it gives us a useful round number with a cost we can all visualize and scale.
8000 users X 18 second event = 1 person-week*
This means that if there is a single problem such as a confusing description, or a missing configuration, or a poorly designed form setting that requires 18 seconds to understand or perform a workaround, then the company pays the equivalent of 1 person-week in salary.
If an 18 second problem occurs weekly for each of 8,000 users,
the true cost is 1 person-year.
If an 18 second problem is affecting those users once a day,
the true cost is 5 person-years of time.
To help visualize the cost, let's put this into dollars. If a user has a salary of $50,000 per year, then the corporation actually pays around $85,000 annually for that employee including benefits, overhead, office space. The costs above work out to:
$ 1,634 = Cost per event
$ 85,000 = If once a Week
$425,000 = If once a Day
That's using very conservative salary, the soft costs can easily be 2X in many companies. It shines a different light on usability bugs, doesn't it?
Here are a few common issues that can easily
cause an 18 second delay for a user:
- Login screens where instructions are poor when users have many passwords to remember (Password requirements are often hidden for security)
- Search results that are poorly ordered or indexed, or where the search fields are in a separate form
- Long paged lists without an easy way to locate a specific element
- Searching for a form or page where naming patterns are inconsistent, or scanning a page where the information is dense and lacks hierarchy
- Broken deep-linking (Bookmarked pages or links sent to another person that break force users to start over from the home page and search or navigate back to a destination)
- Security timeouts where data is lost because the user got up from their desk or had to answer a phonecall
- Filling out a form where known data is not pre-filled (Also, missing make-a-copy features or templates so a user must re-enter all data for a similar item)
- Overly-constrained forms where obscure data is required
- Forms where field labels are incomplete or ambiguous, or where error fields are not highlighted
- Forms that exit at an inconvenient page so where the user has to navigate back to a useful area
*Note:
1 person-week
= 60 seconds X 60minutes X 40 hours = 144,000 seconds
8000 users X 18 seconds = 144,000 seconds
These numbers are conservative - people don't work a full 40 hours a week, and true costs can be much higher, problem events and workarounds can take much longer to resolve. In other words, the problem is actually worse than this example to help counter any objections to the method.
When you re-use this example you can adjust the event seconds to match your known population size. The goal is to find a combination that gives you round man-years so anyone can imagine the potential benefits.
Example: if 10,000 users we could use 15 second events for calculations.