I’m new to the business analyst role (8.5 mos to be exact), and I came across your webinar “6 Mistakes That Lead to Missing Requirements” from Bridging the Gap. During the Q&A portion, a question came up about listing “solutions”, and another about some projects requiring the BAs to provide the developers high fidelity mockups. I’m in this exact situation right now. The team I am part of requires the BA to be the one documenting the design specifications. We’re not so much into understanding the requirements – the developers want to know right away what design specs to implement.
So my question is – is it really the BA who provides the design inputs for developers? Is it the BA who writes the design document? I’m really confused. If I simply give them the requirements (the conditions that must be fufilled), they wouldn’t know what to do. We are in an agile environment, so I know that the line delineating each role tends to get blurred, but I’m getting more and more pulled into the solution space as opposed to staying in the problem/requirements space.
I hope you could shed some light. Thank you!
Before I offer my answer to this question, let’s look at some facts:
1. Most software requirements can be satisfied by more than one software design.
It’s very rare that a functional requirement can only be satisfied by one particular design. For instance, a requirement for a webstore that says “the system will allow customers to write product reviews” could be fulfilled by many different designs, including a button “Write review” that when clicked opens a pop-up window, a link saying “Leave a review” that when clicked shows a sliding panel with the fields to be filled out before submitting the review, and a “reply to this message to leave a review” feature that automatically processes a customer review submitted via email reply.
And note that we’re not talking just about user interface design here. There are other aspects of software design, such as where to allocate capabilities across modules and components, which technical methods will be used to implement a feature, etc., for which there will be multiple designs capable of satisfying a given set of requirements.
2. Shortcomings in user interface design can dramatically limit the value delivered by a solution, even if it implements the right capabilities.
3. As with requirements, great design results from iteration.
The same way that producing quality requirements requires iterating on the problem domain to make sure the requirements address the right problem or opportunity, producing high quality designs requires multiple passes to explore and refine concepts in pursuit of the best solution.
Bottom line: design needs to be taken care of by *someone*, and the best teams wil have designers who collaborate with the rest of the team to design the optimal solution based on the agreed upon requirements.
As you can see from the three facts above, design is an important element that needs to exist separate from requirements and coding. Embedding UI design in the requirements is bad because you’re prematurely limiting how the requirements will be addressed (is a pop-up window truly better than a sliding panel to provide the ability to submit a review?), before different ideas can be explored. And leaping from requirements to coding is bad because it means the design will happen implicitly during coding, without considered thought. It’s like deciding to build a house based on the requirements “must have 3 bedrooms, 2 bathrooms, and 1 kitchen” without thinking through how to best allocate the rooms. You could end up with the requirements met but the residents unhappy that they have to pass through the kitchen every time they want to go from their bedroom to a bathroom, or dissatisfied with the high cost of temperature control because room placement didn’t take advantage of the position of the sun.
An additional benefit of separating design from requirements is requirement stability. If you’re embedding design into your requirements, and the user interaction has to change (say, from clicking a button to using a dropdown) because of a technical constraint or to maintain consistency with how other user actions have been implemented, your requirement (the capability or condition the solution must meet) doesn’t have to change. This can save significant time, ensuring your requirements documentation (e.g., user stories and acceptance criteria) doesn’t have to change, only the design, and user acceptance tests if you’re designing those based on the user interaction.
The main reason we have so many BAs confused about their role and which documents they’re supposed to create is that in many organizations managers aren’t aware of the importance of separating requirements from design and design from coding. Typically in these organizations there are no designers on the team, and developers are rewarded by the number of lines of code written, or user stories implemented, or tasks marked as completed, rather than by truly solving the business problem. This means developers don’t want to “waste time” exploring different ideas on how to implement a specific capability. The BAs in these organizations are left with the task of producing the final design, often with insufficient time to dedicate to understanding the problem and articulating and validating the requirements before jumping into “solution mode”.
Now, should the UI (or, for that matter, the technical) design be done by the same person doing the requirements work? I don’t see a problem with that, as long as the person has the skills and time to perform both jobs well. The reality, though, is that the skills required to produce great UI design are different than the skills required to create excellent requirements, and it’s rare to find the two sets of skills in the same person.
This means that having the same individual in charge of requirements and design may result in a design with great look and feel but that doesn’t solve the right problem (if the person has design skills but not business analysis skills), or a solution with usability issues (if the person has good analytical skills but not the knowledge or or talent to produce a good design).
Here’s an example that illustrates the latter, extracted from a previous project. The requirement stated that users would be allowed to upload up to 3 files concurrently. The BA created a wireframe that looked like this:
When the developer saw how cluttered the design made the page look, he suggested a different design:
(This is a low-fidelity representation created just to illustrate the point; the actual design looked much better.)
In this new version, in the (rare) occasions the user needed to upload more than one file he or she could click “Add more” and the system would add a second line for input. Users agreed that the design change made the page much more readable and efficient for the majority of users navigating from field to field using the tab key to fill out the form with just one file to upload. If the developer just followed the specification provided by the BA, an inferior solution would have been deployed.
But note that regardless of the design choice here, having requirement statements documenting the expected behavior (“users must be allowed to upload up to 3 files concurrently”) is important to reduce the risk of a design choice failing to meet the actual requirement. People could get so involved in the discussion of the best user interface that they forgot what the original requirement was. With a design linked to an actual requirement statement, it’s much easier to remember to address details like the need to prevent users from uploading more than 3 files. Based on the stated requirement, a separate annotated wireframe could be created to show the state of the screen with input fields for 3 files and the “Add more” button disabled.
The most effective teams I worked with had one or more user interface designers available to work on software projects, taking the functional requirements produced by a business analyst and translating them into low- or high-fidelity wireframes in collaboration with the developers and the BA. The business analyst would remain involved throughout the design process, contributing with suggestions and validating that the UI design accommodates all the functional requirements and exception cases and doesn’t incorporate unnecessary capabilities that increases software complexity without adding value.
(The best teams I’ve worked with also had software architects in charge of developing and maintaining a solid architecture of modules and components that made enhancing the system easier over time and ensured performance, security, scalability and other quality requirements would be met.)
But what if I work for an organization that doesn’t hire UI designers and expects the BA to deliver design artifacts to the dev team?
In some organizations without designers, you may be able to find talented developers who have a passion for good user interaction willing to sit down with you to discuss alternatives to implement a given capability (as in the “file upload” example above). In other workplaces, programmers will be unwilling to engage in this effort, and the task will fall on your plate.
The best advice I can give to people who are in a situation like the one described by the letter writer is to try to educate your boss on the importance of separating requirements work from design work. Even if you can’t get help for doing both jobs, at least try to ensure that in each project you have time to dedicate to understanding the problem to be solved and writing requirements that are free from premature design constraints that you validate with your stakeholders before moving to the design phase. Even if your developers don’t care about the actual requirements, *you* should care and make sure that the wireframes you deliver accommodate all the functional requirements and address exception conditions that can arise. And if you don’t have a background in user interface design, you should also try to read about this topic as much as possible in order to avoid making egregious mistakes when creating wireframes for the development team.
And, when you’re looking for a new job, ask about the company’s practices as to what pertain to requirements, design, coding, and testing. If given a choice, go work for a company that already sees requirements as an essential step on the path from business needs to satisfied customers and for managers who insist on creating designs on a foundation of high-quality requirements, as this will dramatically increase your ability to deliver successful solutions.