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 :
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.
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.
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.