Usability vs. Scope: Fight!

A project I’m currently working on is encountering a problem that I believe is not all that rare.  They are faced with a challenging question mid-project: should the team focus on producing software that is easy to use and learn, or should they focus on getting as many features and bug fixes in as possible before the final release?  I have seen many people frustrated that we can’t seem to have our pie and eat it too – we can’t seem to find ways to “do usability” without somehow impacting the project’s timeline or scope.  And sadly, at this point in time, I agree that this is true for this project.  Kinda.

I’d like to take a closer look at these two options, and propose a few solutions for future project teams to consider.


Round 1 – Scope Wins
A product can almost never reach its full potential when it is first released, nor upon successive releases.  The truth of the matter is that people can envision the next cool or useful feature much quicker than anyone can code and test it.  In fact your competitors are most likely putting those cool features into their next version while you are trying to put out the latest version of software designed to hit feature parity in the market.  Not only does your product’s next version need the blinking lights and rounded corners – it needs to differentiate itself in the market.

So the idea of removing planned features, of putting out a product that actually offers less functionality than the competition is seemingly a hard one to get behind.  This is the wall that usability efforts often come up against.  Almost everyone agrees that having a usable and intuitive product is a good idea, if not a great idea.  However it is difficult to quantify the value of “usable” and “intuitive” for many UX teams.  The product is late, the existing customers are tired of waiting for enhancements, and the market seems to be moving too fast to keep up.  So naturally scope wins here – you want to put out a product with features, and no bugs (keeps those support costs down).  Best efforts will be done to incorporate usability efforts, but only when there’s time and resources available.

Round 2 – Usability Wins
People love great software. Today most computer users are drenched in software. They are inundated with new applications on a daily basis via appStores, product reviews, software suggestions from friends, and any number of online software repositories such as SourceForge and GitHub. So how do your users determine which software they will continue to use? There’s a strong hint in Apple’s AppStore – a random sampling of 5 applications is almost guaranteed to include 4 applications that claim to be “intuitive” or “simple”. The truth is that people aren’t looking for an application – they’re looking for a solution to their problem. And guess what? People want to solve problems, but they’re oftentimes not willing to work very hard at it. In other words, your software must be something the user will actually use. Call it intuitive, call it low barrier to entry, short learning curve – whatever. If your users aren’t enjoying using your software they will find ways to not use it – simple as that. And what do you call users that don’t use your software? That’s right – potential users a.k.a. “Back to Square 1”.

So where does usability come in here? In a general sense, usability helps to ensure that your users will find your software useful. If you aren’t running usability tests with neophyte users you’ve probably missing out on the fact that there’s a major problem with a part of your software that will result in the user getting frustrated and returning to other alternatives. If you’re not ensuring that the user’s goal is satisfied in the software then you can stuff as many features into it as you want but people still won’t use it. Features are important, but only if done right.

So Now What?
The two descriptions above paint a rather ominous picture. Don’t despair though – its not as bad as it seems. There are some things that can be done to avoid having to make the call between these two idea(l)s.

  1. Bake in usability. When doing your project planning you need to figure out the scope of the project, the effort required to attain the milestones – all that good stuff.  It is extremely important that you also consult with a usability expert to find out how much effort is required from a usability standpoint to bring the project to a successful end.  Ensure that sufficient time is planned to allow for usability testing, design exploration, user consultations, survey – whatever is needed in your project.  Include that time in your project planning – they are vital project activities.
  2. Take usability seriously – it is a skill. Don’t just assume that your Visual Designer will be providing a usable interface. Ensure that you get effort estimates and planning input from someone with both knowledge and skills in interaction design and usability.  This could very well be your Visual Designer, but don’t make the assumption that anyone working in the “UI” understands and applies usability and user-centered development best practices.
  3. Incorporate usability into your requirements.  Requirements are a key part of software development.  They help guide the team towards the desired end point by describing the problem to be solved and how to solve it.  Should the requirements not also describe who is going to use the end product, in what setting, to achieve what goals?  ISO seems to think so.  Consider documenting interaction and usability-related requirements as part of your business and software requirements.
  4. Leverage testing. Testing your software is an accepted and often required practice.  Leverage the fact that someone is going to be “touching” almost every part of your code while testing it.  Can you find users to help validate your software while also verifying it?  Sure it works as specified, but does it work as intended and as needed by actual users?  What is your release criteria for the end product?  Does it incorporate the idea of validating the end product?  Would your testing uncover a critical usability issue and can you hold up release until it is fixed?

But My Project Is Already Underway!

The ideas above are most helpful when planning a project, and fall somewhat short of helpful if you’re already enmeshed in the day-to-day grind of a project.  So is all lost for those projects that weren’t able to give some early thought to usability?  Not at all, but my advice gets a little less straight forward in these situations.  A few thoughts to consider:

  1. What does success mean anyways? Look at what are the success criteria set forth by the key project stakeholders.  If the product were to come out with all its scoped-in features but fell flat in front of users as too complex or obtuse, would the project still be a success?  This is not a glib question – the answer will be yes for some of you.  There’s always release 2, as some say.  But often it can be possible to look back at those initial success criteria set out for the product and argue that some features could be moved to the next release in order to ensure that the first release is successful enough.  Hopefully successful enough to merit a second release.
  2. Get some outside help. Don’t tell the UX union I said this, but I think it is SOMETIMES possible to bolt on usability, just a little bit.  That little bit is better than nothing and can often go a long way towards a better product.  Look into getting a limited engagement with a UX expert, perhaps just a simple heuristic evaluation could help.  Perhaps the team just needs some rough personas to help galvanize and focus their thinking about the user’s needs.  UX doesn’t have to be glitzy and involve fireworks – sometimes little bits help and the slush fund could be put to good use.
  3. Involve UX in scope decisions. Your UX team should have the best grasp on what the user’s interaction needs are.  Your BAs (if a separate team) will know the user’s needs.  Together these two skillsets and knowledge bases should be used to help make the right scope decisions.  If a feature must be included UX may be able to figure out a quick and easy way to get it “good enough”.  It may not be the dreamt-of vision but it will get the job done, ensuring your users get their job done.  UX may also identify some features as being high risk in terms of design and usability.  Use this to help refine scope as you go.  Choose your risk rather than finding out once the product is released that you unknowingly gambled on uncertain design decisions.

Scope and usability are two competing ideas, but they are not mutually exclusive.  You can have both, given appropriate planning and determination.

Leave a Reply

Your email address will not be published. Required fields are marked *