Matching Requirements with User Experience

Turn evil into good.

In my years of reading requirements, I’ve come to loathe the genre. As a written statement, the “requirement” is a somewhat strange and antiquated way to capture what a software system is supposed to do. I have no desire to discuss new and better ways to write requirements in this article, since others have written powerfully and persuasively about transforming this oddity into more useful forms such as user stories, use cases, and “minimum viable product” specifications.Learning how to deal with badly written requirements is part of our job, but they can be a trap for the designer. How can the user experience designer handle the inevitable dysfunction that badly written requirements create in his or her relationship with the business analyst? In this article I’ll offer some practical advice on how to deal with this dysfunction and position the designer as someone who needs to be included early in the project–before requirements are written.

The Dysfunction of Requirements

The causes of the dysfunction are at least twofold.

First, large internal IT projects are scoped by the two roles least equipped to come up with great user experiences: the business analyst and the stakeholder. Neither typically has any formal training for envisioning highly intuitive and usable systems, and the stakeholders are typically pulled in multiple directions. As a result, the requirements usually are incomplete and written in haste.

Second, project-budgets and timelines often are defined with the hastily written requirements as the primary input. This puts designers into a difficult position as our work inevitably leads to new features and requirements that may greatly improve the outcome but not fit into the budget. What is worse, you are often stuck designing a system that can never be usable, but you’ll get blamed nevertheless.

I suspect that the reason for these dysfunctions dates back to a time when software systems were largely about automating internal processes. The 1990’s drove an acceleration of this approach mainly in response to “Y2K” and ideas like “business process re-engineering.” A lot of IT spending and hiring was driven by the removal of home-grown systems and replacing them with big packaged systems from SAP, Oracle, PeopleSoft and the like. Many of the business analysts writing requirements today got their first jobs then. They became skilled at decomposing and diagramming processes – swim lane diagrams, workflows, and, yes, spreadsheets full of requirements.

At the heart of this approach is a key assumption – the users will be trained. For this reason, there is no need to think seriously about a high quality user experience. Any difficulties in the UI will be addressed in training. The users are also assumed to be frequent, repetitive users: they’ll eventually learn how to overcome the idiosyncrasies of the system.

As the ‘user experience’ has become essential to the success of many systems, the relationship between the stakeholder and the business analyst has not been kept up to date. Many projects still start with the same approach – quickly make a list of requirements and establish a budget under the assumption that the requirements are comprehensive and complete. This creates problems for designers. How do we break into this relationship and get an early seat at the table?

Respect the Situation and the Work

The first thing we need to do in these situations is respect the requirements and reference them in our deliverables to make clear that we are paying attention. Be prepared to recognize when your design introduces new requirements or significantly expands existing ones. We need to be up front about this and call these situations out as part of our design process.

Here’s an example from a recent project, typos and grammatical and spelling errors intact:

Some business analysts reading this will say, “These are terribly written requirements.” And I agree, but unfortunately, this is typical of large-scale projects. They are desperately trying to be complete, but what a terrible way to describe the scheduling of an appointment. There is nothing that explains the context of use and the goals of the system. You could certainly design a system to meet the requirements, but without additional context, it wouldn’t likely meet larger business objectives. Our design turned the requirements into design patterns for a calendar day that includes an interaction model, design justification, guidance for the visual designer, reference to specific requirements, and relevant source systems.

In these patterns, our design defined a new requirement that would automatically select the first available appointment. (We usually assume that fewer clicks in a call center application has direct financial benefits, so why make the CSR search and find the first available appointment?)

As written, BR95 said:
Available Scheduling Message Box
Once the User has selected an Appt Time Slot the following message box will be displayed :
Appointment Scheduling:
The Date you have selected is:
Day, Month, Date, Year (Ex: Wednesday, February 9, 2011)

This requirement implies that a user always has to select an appointment. We didn’t just let it slide, hoping that it would just get through. We called the business analyst and the architect to openly discuss it with them before a formal review with stakeholders. They were fine with it, and even appreciated being brought into the process.

A big win for the designer. But the bigger win happens when it opens the door for getting involved before budgeting in the next project. We just have to have the courage to take that step.

Collaborative Clarification

In another situation we were given the following vague requirements:

We used this as an opportunity to introduce user stories as a way to clarify and unpack all the functionality necessary to make sense of these.

We presented this to the business analyst and stakeholders to solicit additional detail before we tried to design anything. This gave us an opportunity to steer the conversation toward method and introduce an alternative way of formulating requirements in the future. As the designer, your challenge is to be ready to have methodology conversations for the next project that brings these realities to light.

Final Thoughts

As traditionally written, requirements are designed to produce conflict. It is an item for IT and “the business” (to use the common IT term) to negotiate when money and timelines take center stage. That they were hastily written in the first place only makes the conflict more likely. It also sets the designer up to be the fall guy for a poorly conceived system. Recognizing their inherently conflict-driving nature, the designer can work to diffuse the situation and get a seat at the table when the next project starts.

Greg Laugero

Greg Laugero is a digital product strategist and Co-Founder of Industrial Wisdom. He helps companies turn their ideas into real products with great user experiences. You can follow him on twitter: @prodctstrategy.

8 comments on this article

  1. Mide S on

    As a front end developer working with Business Requirements for a legacy application, this article really hits home. In my current job the BA/QA/PM are the big guns. The business needs come first and the IT / developers simply have to please the BAs and client. Somehow I need to be able to convince these guys that the client does not always know best and the BAs really have no clue what a great web site looks and feels like.
    One major victory was to remove IE 6 support from the requirements!!

  2. Greg you clearly articulate the plight of so many projects today. Yet convincing sponsors to invest more up front to save more later is still often a challenge.

    My company Brain Logic works in a similar space as Industrial Wisdom. We focus on working with Project Managers to identify activities needed to be built into the project schedule in order to develop well articulated business requirements that reflect the voice of the customer.

    So glad to have someone else educating on the benefits of this approach.

  3. Stacia on

    Thanks for bringing home some reality in the UX for software space.

    At my job, UX designers and BAs work side-by-side…we’ve evolved (over 4 years) into a checks-and-balances system. Our respective documents should reflect each other’s talents, and when they don’t we compare and seek the best solution.

    Some new BAs have trouble relinquishing control, but once they realize that we do half their analysis, and do it well, they are happy to work closely with us for the length of the project.

  4. Pingback: Användbara länkar v. 26 | Samir Fors

  5. Octavia Maddox on

    I think this article misses an important point. The business requirements are the design – it is just not clear what the design is. In the example presented, the business requirement “alert message set up for ordering” implies a design that requires a person to take an action when an alert is presented to them. As a user experience professional, I need to take a step back and design the system within the user’s context. My first question would be, ‘does the user need to perform an action? Can’t this be automated? If not, how will the alerts sit within the user’s context and all the other system alerts they have to deal with?’. Lists and written statements are the least efficient way of documenting requirements. Sketching, wireframing and experience maps / pathways are the most efficient way of communicating with business and IT stakeholders. I agree that the designers need to be involved as early as possible. However trying to work with vague lists is a waste of time – best off sketching then getting a BA to update their list retrospectively. In my experience no one ends up using the lists of requirements for anything. They are too busy designing,iterating and building. Agile is a reaction to these huge reams of paperwork generated on projects for no benefit. Using lists to manage requirements also stiffles innovation as it does not allow groups of people to collaborate and iterate a design effectively.

  6. @Greg Laugero – Nicely and well done article!

    Thank you for sharing the before and after requirements docs – most helpful and illustrative.

    Your historical analysis, human nature and business pressures analysis, and explication of how teams typically work, in your deconstruction of the problem phenomena was superb. Really demonstrates your depth of clarity and experience.

    “Learning how to deal with badly written requirements is part of our job, but they can be a trap for the designer. How can the user experience designer handle the inevitable dysfunction that badly written requirements create in his or her relationship with the business analyst?” <– The real gold!

    "They became skilled at decomposing and diagramming processes – swim lane diagrams, workflows, and, yes, spreadsheets full of requirements." <– Utterly spot on.

    In fact, these artifacts are the meat and potatoes of the typical BA, and the work product they are most proud of, and through which, how they perceive that they demonstrate and prove their value-add.

    As a DBA and DB Dev (and former front-end developer who marvels at the work of talented UX designers), when reaching out to a BA on a project that is suffering from "technical anomalies", always ultimately caused by the dysfunctions the article describes, the BA typically proceeds to hand over to me their swim lanes, spreadsheets, and printed stacks of email threads.

    I always cringe inside, and after I allow the BA to take me through their works of art and precious children, sucking 45mins from my day, I inevitably say something like this;

    "You are aware that the problem here is the way the front-end devs have implemented the UI, which is causing the users to double POST. To make matters worse, the devs have improperly implemented their roll-their-own database transaction handling system in the middle-tier along with their business logic, compounding the whole problem.

    You do remember that I told you to suggest to the devs very firmly that they call into stored procedures and simply pass parameters around off the query strings or posts?

    Did you work with the design team on this UI?

    Did you speak to the devs like I asked you to and firmly tell them to use Stored Procedures, and to not do their own database transaction handling?

    What did the designers recommend? Why wasn't it done? Why are the devs doing exactly what I told you would cause you and I pain, suffering, and late nights?

    Why weren't any of these issues addressed prior to now?"

    The BA inevitably stares back at me non-plussed, and turns my attention back to their swimlanes and excel requirements tracking matrices, and tries with desperate passion to convince me that all the answers are in their stuff.

    @Jill – "working with Project Managers to identify activities needed to be built into the project schedule in order to develop well articulated business requirements that reflect the voice of the customer" <– as a very high-level theoretical best case, I suppose it is impossible to not agree with this statement.

    That said, the "voice of the customer", whatever that means, should be properly understood as belonging to and representative of all participants in the dialog between end-users, BAs, designers, business managers, software devs, and the DBAs – these are all the real "customers".

    The fundamental lack of awareness among most IT shops of the interdependent nature of the complexity that is application development, coupled with a general lack of appreciation for the interdependent nature of each given team member's work product upon each other team member's work product, is the chief cause of the dysfunction the article seeks to show designers how to better insulate themselves, and the final product, from.

    @Octavia – "The business requirements are the design – it is just not clear what the design is." <– I agree, but with the following commentary: the problem with the requirement statement you speak to is that it conflates a functional requirement, "make user aware of X", with how to implement that functional requirement, "display an Alert box".

    As you say, display Alert box as the UX/UI implementation of the functional requirement that "the user be told something", does not provide adequate detail for the designer.

    The actual difference between functional requirements and how to design and implement those functional requirements, the difference between business logic requirements versus the technical design requirements, and the difference between the technical design and the technical specification which details how to implement the technical design, are all differences that are hardly well understood and fully appreciated – even by folks who have done this work for a long time.

    Conflation and misunderstanding of these differences and artifacts is wide-spread, and goes a long way to causing most of the trouble and frustration that everyone in the drama, and the end-users most of all, suffer from.

    It Works Like This ::

    The designers are left asking themselves what the requirements "actually mean", as while best case the functionality desired may be clear, there is precious little to guide them in the implementation.

    The end-users don't understand much of anything about this stuff, and just wish that things weren't so difficult to use, and that the UI wasn't so complicated and counter-intuitive.

    The devs just wish the BAs actually knew what they were doing, and that the DBAs would stop their monotonous harping and tireless advocacy of Stored Procedures Everywhere.

    The BAs wish the devs would just do what they're told for once without whining and complaining, and wish that the end-users weren't so retarded.

    The DBAs just wish the devs weren't such loose cannons, and would at least attempt to use stored procedures once in awhile, rather than playing fast and loose in the middle tier.

    And at the end of the day, the poor BA seeks often seeks out the DBA, because we are usually the most even keeled emotionally, and crys on our shoulder, and tells of the travails that no one else seems to understand, how impossible their job is, and how hard they work for their $85k – $125K salaries.

    And often later than anyone else, the DBA leaves work, gooes home, and late at night writes long article comments trying to tell everyone on the internet what the real situation actually is. ;+)

    @Stacia – "At my job, UX designers and BAs work side-by-side…we’ve evolved (over 4 years) into a checks-and-balances system
    Some new BAs have trouble relinquishing control…" <– Where do you work? Are they hiring DBAs???

  7. Pingback: Matching Requirements and User Experience « Greg Laugero

  8. Pingback: 'UX interpretations' as a UCD technique -@-