In this post, you’ll learn more about:
- How Business Analysts traditionally see requirements;
- How UX experts also play with requirements, even if they don’t know it;
- What is the full requirements spectrum (hint: it’s not only about the system);
- How you can add depth to your UX practice using requirements
A few weeks ago, one of my colleagues was quickly explaining the role of the UX team on a new project starting. He simply described it as a way to highlight requirements for the project in a visual way. The funny thing is that for most UX specialists, the word “requirement” is at best something that someone else is managing and that they don’t need to care about. On the other side, BA experts think about requirements, work with requirements, and evangelize the importance of requirements.
At that time, my first thoughts were that it was a very limited understanding of what UX can do. With my unique BA + UX role, I realized that my colleague was indeed right. And even if UX specialists don’t specifically talk about requirements, they deal with requirements as often as BAs.
Let’s see how we can make UX practices better by looking at how business analysis is managing requirements.
Disclaimer: requirements are not a meaning of waterfall (unless you spend a specific period of time to elicit all of them). Agile also makes use of requirements; they just call them epics & stories 🙂
How BAs traditionally see requirements
Early in my career as a BA, I had to start documenting requirements using a very formal, waterfall approach. I did that using way too many different tools, sophisticated and improvised. In the end, I could summarize all of them by saying that they could have fit within a traditional spreadsheet format.
I usually started with high-level needs describing the business goals. Then, I worked out more refined functional requirements that would eventually lead to other documents. Indeed, it seems like spreadsheets are not always the best format to capture detailed use cases & business processes, interfaces or system flows.
I’ve spent hours with my stakeholders to walk them through those spreadsheets so that they can approve them. When I was lucky, people were asking questions trying to understand the requirements as we were reviewing them line by line. Most of the time, they just nodded as I was guiding them through the documents.
I quickly realized that storytelling was a really underestimated technique! I eventually switched to a more entertaining and meaningful approach to share elicited needs with stakeholders and get true approvals. Using sketches, diagrams & more visual artifacts, I was able to create that shared understanding that makes everything much easier in a project.
Recently, when I started wearing my UX hat, I realized that I was applying a design approach to my BA work. I just didn’t know it yet 🙂
Understanding the requirements spectrum
As a BA, I was trained to elicit & manage requirements at different levels of detail. When I started working with UX experts, I realized that they were also eliciting & managing requirements. However, most of them focused on solution needs only. While these are important, ignoring the other types of requirements can lead to a useless solution.
So, what can a UX expert do? He needs to know what he doesn’t know.
I always had a hard time finding a good & simple definition of the different types of requirements, so I decided to create my own based on my experience (and this great article on the matter).
Business requirements (why are we doing something)
Business requirements are the organization’s goals & objectives for a given product/project/initiative. It comes down to what the organization wants to achieve for its customers (which could be internal, or external to the organization).
For example, your organization might want to offer a new product to your client base; improve the employee experience; or comply with a new regulation. Based on my experience, you can usually count them on the fingers of one hand.
Stakeholders’ requirements (how will we achieve it)
Stakeholders’ requirements are taking business requirements to a more detailed level. Their goal is to describe what they expect from the solution, in order to support the business requirements. While your stakeholders might expect specific system capabilities, they will also have expectations regarding staffing, training, marketing, regulation compliance & support (among others). Stakeholders’ requirements list can be large or small, but ultimately it will be as good as your stakeholders’ analysis. (link to some article)
Solution requirements (what will the solution look like)
The characteristics of the solution that are needed to support business & stakeholders’ requirements are solution requirements. While we often see “solution” as the system solution, the “solution” will encompass more components than that. Think about the characteristics of business processes or communications & touchpoints required to support the system solution, and you’re now on a more challenging elicitation journey!
Solution requirements can be functional or non-functional. The former are the expected behaviours of the solution (ex: when this happens, the solution will do this). The latter describe the context in which the solution will meet higher-level needs (ex: performance expectations for a system interaction or a business process cycle).
Transition requirements (how will we get there smoothly)
Even seasoned BAs forget them, but I think they are critical to any initiative. They are also the key to make an agile approach feel more considerate by your stakeholders. Transition requirements describe the temporary characteristics of the solution that will exist during the transition from the current to the desired state. A good example of a transition requirement is the manual, human-based workarounds needed until the system solution can support a specific use case.
Including transition requirements in your MVP definition can also be helpful to manage your stakeholders’ expectations. For example, being able to manually export data from a system to support analysis in a spreadsheet can be a transition feature until dashboards are added to the system.
How to add depth to your UX practice using requirements
At this point, you should now know what you didn’t know about requirements earlier. Let’s see how you can leverage this knowledge of requirements to improve your own UX practice and get more value from your own activities & artifacts.
Reassuring side note: you won’t start creating spreadsheets to elicit & manage them 🙂
1. Capture Business requirements to guide your UX process
Identifying business requirements early on will be helpful to define the UX approach you will want to follow. They will help you to identify if you’re on track (you know, that thing called scope?). If they are not clear to you, you might want to take some time to clarify them with your stakeholders before starting to work.
Jobs to be done & Customer journeys are useful UX artifacts that can be leveraged to make sure that business requirements are well understood by everyone. Since they highlight your end customer objectives, they are usually a good representation of them.
2. Draw on Stakeholders requirements to define your UX sandbox
One of the key UX artifacts that can be used to elicit stakeholders’ requirements is the service blueprint. Because they highlight all the activities & interactions happening behind the front scene, service blueprints are a great way to investigate what internal stakeholders will need from the solution in order to support the desired, front-stage experience lived by the customers.
A good service blueprint will guide you in your discussions with stakeholders. It can also help you identify less obvious expectations about your solution. And it will help you to express stakeholders’ expectations in a more meaningful, storytelling-oriented way.
3. Bring Solution requirements to life with common UX techniques
In my early years, I struggled a lot with solution requirements. That is, until I started using wireframes to document them. Unsurprisingly, it’s WAY easier for anyone to understand & validate the behaviour of a solution with a visual representation of it. Adding specifications to your wireframes will also bring your relationship with development teams to another level.
They say that an image is worth a thousand words. We could also probably say that a working prototype is worth a thousand images. While prototypes are usually not the best way to communicate solution needs to your development teams (at least the ones I worked with), they are fantastic to validate that they are aligned with your users’ & stakeholders’ expectations. I also often use them to tell the story behind the solution and highlight the solution needs.
While non-functional requirements are harder to prototype or illustrate, you can (and should) document them somewhere. This way, you can have the appropriate discussions with your development teams. I still haven’t found a better way to document them than using a spreadsheet or a wiki-style document. If you have one, please share it with me!
Requirements spreadsheets are (almost) dead, long live wireframes & prototypes!
4. Leverage Transition requirements to go from unicorn solution to MVP
Most of the UX experts I worked with are usually thrilled about their solutions. This remains true until they have to deal with the reality of technical constraints, shorter timelines and limited budgets. Suddenly, their solution becomes a mere shadow of itself.
However, this reality check should just be an opportunity to design transition solutions to bridge the gap between the current & the unicorn states. Those constraints can be leveraged to define temporary service blueprint elements to offer a seamless customer experience, or to design workarounds that are really user-focused.
In the end, transition requirements are a major opportunity to boost your value as a UX specialist and demonstrate a holistic & realistic understanding of your organization. All of this without compromising on the user experience, and while leveraging common UX techniques.
Do you like what you’re reading?
After writing this article, I was more than reassured about my hybrid BA & UX role. Did you find something helpful to improve your own practice? Share it in the comments below!
Photo by Devon Divine on Unsplash
