Design-Free requirements are important for two reasons, and hard for two other reasons.
Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.” Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.
Design-Free Requirements – Revisiting
It has been three years since I wrote Writing Design-Free Requirements as part of The Big Ten Rules of Writing Requirements. In that time, agile development practices have moved from being an esoteric development methodology to being the topic on the tips of everyone’s tongues as executives and organizations try to either (1) get the benefits of the state of the art in software-development process or (2) do something shiny and fashionable.
The previous article centered on elements of designs within MRD, PRD, and SRS artifacts. A regular alphabet soup of artifacts. Honoring the values behind the agile manifesto encourages us to emphasize working software over comprehensive documentation. In that light, we’ll take a “what is needed” approach to talking about how requirements, design, and implementation are all needed – rather than issue an edict about where that information should be captured.
Agile Development Inputs
When creating software, someone needs to know:
- What problems are being solved, and how important (valuable) they are to be solved.
- Who has the problems and who is using the software to (help) solve those problems.
- What constraints limit the space that defines the universe of possible viable solutions.
- What acceptance criteria define if the delivered solution will be acceptable.
Subject to those inputs, someone needs to make design decisions:
- User experience design - what interactions will a user of our solution love?
- Program design – how (in a nuts and bolts way) will our solution function?
When talking about agile and talking about design, we should take a look at how Kent Beck and Alan Cooper, as respective though leaders in each space, view this.
Cooper doesn’t talk much about creating the requirements to support the daily use scenarios – he proposes moving directly into design of the solution. This differs from the more traditional technique of writing functional requirements to support use cases. Cooper also breaks down design into two components – program design and interaction design. Program design is everything you don’t see. Interaction design is everything you do see.
[...]
Cooper argues that designing the interaction should happen before any code is written. He uses a construction analogy to drive home his perspective – you can’t pour the concrete before you build the forms. Kent Beck, founder of the XP programming philosophy disagrees with the premise. Beck believes that the cost of changing software is low, and the imagery Cooper uses is hyperbole. We touch on, and link to that debate in this post.
I don’t believe that Beck is arguing for “don’t do design” – I believe he is arguing for “don’t do big upfront design that would delay implementation.” He’s championing the agile values that emphasize creating working software and responding to change. I can imagine him saying “no one will buy a design, they want a solution.” Cooper’s point is that create a solution without first understanding how someone will use it, you can’t create a great product.
Program design has many hidden impacts – cost of maintenance, cost to change, and the performance of the solution. You can have a design (or architecture) that makes everything easier to do in the future – at the cost of delaying the delivery of anything. Or you can have a design that minimizes the time to deliver the first thing, while increasing the cost to deliver any particular next thing. Or you can design a solution that falls somewhere between those extremes.
If you say “we don’t do design” you’re lying. Every solution includes design. Your team’s design process may be “big and upfront” or it could be a couple sketches on a whiteboard, or some email exchanges. You may create storyboards and wireframes. Or design may be the thing that happens right before the programmer’s fingers strike the keys. Design may be explicit or it may be implicit – but it never “doesn’t happen.”
In the movie Amadeus, Salieri is astounded that there are no rough drafts of Mozart’s compositions. That’s because Mozart did the design in his head, not because he didn’t do design. I’ve worked with programmers who’s “implicit designs” were great, but that is the exception, not the rule.
Who Owns Design?
Since design happens sometime before fingers strike the keyboard, the real question is – “who owns the design?”
- You have a product manager developing an understanding of market problems, and prioritizing the problems that should be solved with your product.
- You may have a product owner managing the backlog and clarifying those requirements (problems) for the development team.
- You may have an interface (or interaction) designer or team of designers who are broadly responsible for “how users interact with our products.”
- You may have an architect or lead engineer who is responsible for the “big picture design” of how your product works.
- You have developers and testers who are responsible for delivering your product. [Note: coding without testing is like typing code without compiling - maybe it works, but probably not.]
You may not have distinct individuals with each of these titles – every small team I’ve worked with has people wearing multiple hats. This is especially true when you have an agile team full of specializing generalists – any given story (or task) may have a different architect and different implementer. I’ve only worked with one company where the architects are NOT part of the development team. If your team is set up that way, please comment below – I had never seen that before, and I’m not convinced that it is the best way to organize – what have your experiences been?
Generally, “program design” is clearly owned by the development team – and product managers (and product owners) know better than to specify program design in their requirements. Neither the lead engineer nor the product manager believes that the product manager is a better programmer – so the product manager better not be specifying program design and mislabeling it as requirements. Coincidentally, Steve Johnson, at Pragmatic Marketing has a post running right now with a bit of a quiz – is this a req(uirment) or a spec (design)?
Where the line is more blurred is around interface and/or interaction design. Some development teams have interface designers as part of the team. Some companies organize with interface design as a “shared service” within the company. Either approach can be the “right one” – it depends on too many details to make a sweeping generalization. When the designers are members of the development team, the solution (from a product management perspective) is the same – the “team” is responsible for all design. When the designers are not part of the development team, the developers have to consume two sets of guidance – “solve this problem” from product management, and “the solution needs to look like / act like this” from the designers.
Collaboration between product management and user experience people is the ideal solution. The “requirements” and “design” inputs to the development team are comprehensive and consistent.
Design-Free Requirements
There are benefits – especially when being agile and minimizing documentation – to delivering requirements and design at the same time. Just don’t do it by embedding design constraints within the requirements.
- When people on your team misinterpret design as requirements, they are unnecessarily constrained.
- As a product manager – are you the best designer on your team? If you’re busy designing, who’s product managing?
This is trickiest when writing use cases – sequencing a set of interactions is interaction design. That is one benefit of writing a user story instead of a use case. An approach that has worked well for me with multiple teams is to deliver user stories (requirements) combined with storyboards (interaction design) and wireframes (interface design). When details are needed (usually when “changing” versus “creating” an interface), screenshots can replace wireframes. When business processes are complicated, process flows can replace storyboards.
Just don’t embed the designs within the requirements.
Latest Articles
Comments on all Articles
