UX-Driven Design
In this chapter from Modern Web Development , Dino Esposito presents the concept of UX-Driven Design (UXDD), a top-down approach to implementing the supporting architecture for your chosen system.
Talk is cheap. Show me the code.
—Linus Torvalds
It’s common to hear developers complain that customers change their mind too often. The narrative goes something like this: “We discussed requirements for weeks and signed off on specifications. Then we started coding, and when we delivered the first sprint two weeks later, we found out that the program was only vaguely close to what they really wanted.” This experience is summarized in a popular cartoon where the waiter gets a complaint about the coffee he just served. “We use top-quality coffee and the best machine available. What’s wrong with the coffee, sir?” And the customer’s answer is kind of shocking: “I actually want some tea.”
The process of elicitation has always been difficult, and the Ubiquitous Language pattern I discussed in Chapter 1, “Conducting a thorough domain analysis,” as the foundation of Domain-Driven Design (DDD) addresses the topic of communication between the various stakeholders involved in a software project. However, agreeing on abstract requirements and specifications is often not enough. When customers actually see the artifact, they might not like it. Despite all the talks you had with the customer, they might have formed an idea that is actually different from yours.
This is to say that to reduce the costs of software development, and further reduce the number of iterations to figure out what exactly users want, an additional level of agreement must be found beyond Ubiquitous Language. Creating a common language shared by all stakeholders and widely used in all spoken and written communications is of immense help to ensure that each word spoken is understood correctly and, subsequently, software specifications are correct.
You know, however, that talk is cheap and to give customers a realistic perspective of what you’re going to do you should show some code. But code also is expensive to produce, and nobody likes the idea of writing code that might be thrown away if some assumptions made, and not clearly resolved by specifications, turn out to be wrong.
In this chapter, I’ll present UX-Driven Design (UXDD). UX stands for user experience, and UXDD is a top-down approach to implementing whatever supporting architecture you selected for the system. UXDD differs from most commonly used approaches in that it emphasizes the presentation layer and the actual screens the user will end up working with. The main trait of UXDD is that, before you get into coding mode, you have customers sign off on wireframes and storyboards for each task offered through the presentation.