Difference between user requirements and specifications

This is a blog post I wrote for the intranet at my previous workplace to help influence a change in thinking in what constitutes “requirements”. Often, business will hand down “It must look like this and must work like this” which significantly constrains the design and is based on a lot of assumptions, competitors’ products and previous requirements. Plus it short-circuits any knowledge of technology, trends and patterns that the design and development team could have contributed.

User requirements should detail what is needed by users; they should define the problem, the space within which a solution can be designed.

UI specifications detail a particular solution that can be implemented to meet the identified requirements.

There should be a clear and traceable relationship between every element of a design and the requirements.

The requirements and the specification can be in the same document but it should be clear that the requirements are defined and accepted first and that they are fixed whereas the solution specified is just one way that the requirements can be met.

Elements of a solution that cannot be traced back to a requirement indicate incomplete requirements or surplus design.

The following words should typically not be used when discussing user requirements as they refer to a user interface solution and confuse the purpose of a requirements document, preempt solutions and constrain the design, possibly excluding the optimal solution:

button, screen, panel, drop-down, list, scroll, click, tap, calendar, flip out, fold, animated, swipe, heading, label, line, grid, table, row, column, select, drag and drop, window, resize, right click, menu, sort, map, link, widget, box, icon, see, hear, touch …

This is a confused user requirement:

“A user can sort the table by any of the columns”

Rather, the user requirement might be:

“A user can opt to view the tabular data in ascending or descending order on any element of the data”

And the matching UI specification might be written (or committed straight to wireframes) as:

“In every cell of the header row will be two controls visible at all times, one for sorting the relevant column in ascending order and one for descending order”

Though preferably the requirement would be even more high-level (and yet more specific) so that we can understand why they might want to sort the data:

“A manager can identify the driver with the highest revenue for the week”

Ah. Now we have something that doesn’t tell us what screen or page this needs to be on, it doesn’t talk about tables or columns or sorting, but tells us what the user actually needs. This does require digging deeper into customers’ business, delving into latent needs analysis and pushing past what they ask for (a table I can sort) to what they’re trying to achieve. This is not always possible especially when there is no precedent or process for that calibre of design research, but it is something to aspire to and agitate for.

The UI specification for the clear user requirement could also be for a drop-down list outside the table or a single toggle icon button in each column header or any number of solutions which would be at the discretion of the designer who takes into account the user requirement in the context of usability principles, the established interaction conventions within the application, the strategic direction of the UI, brand identity, task efficiency, frequency of use, reducing change of slips and mistakes, interaction with a product from a variety of platforms both desktop and mobile, touch and non-touch, with and without a mouse, those who prefer keyboard navigation or use accelerators / shortcuts, those with vision impairments including protanopia and deuteranopia, the environment context of the workplace which may include being in a vehicle or walking down, the ecosystem of other processes and software that users may typically used (Microsoft Outlook, Excel etc) and may be familiar with to leverage idioms and patterns, emerging design trends and so on.

This of course means that designers need to be exposed to the full suite of intelligence and insights that we have on customers and users otherwise they’ll have to resort to making an awful lot of assumptions.

If you enjoyed this article please share it with your friends and colleagues.

Comments

  1. Adan Fendrych says:

    Great article!

  2. Yes give me the intent and a story from the user, not a requirement.

  3. Thank you for another informative website.
    The place else may I get that type of information written in such an ideal method?
    I have a project that I am simply now operating on, and I have been on the look out for
    such info.

  4. We’re a group of volunteers and starting a new
    scheme in our community. Your site provided us with valuable
    info to work on. You have done a formidable job and our entire community will be thankful to you.

Speak Your Mind

*