WEBSITE DESIGNER SEATTLE—It’s widespread to hear professionals complain that clients change their minds more often than others. The narrative goes something like this: “We outlined requirements for weeks and signed off on so many details and specifications. Then we moved on to coding, and when we delivered the very first sprint two weeks later, we saw that the program was only vaguely close to what they really wanted.
This incident, or now as we call it, “our experience,” is categorized and summarized in a famous animated show 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: “l actually want some tea.”
The process of elicitation has always been complicated. However, agreeing on abstract requirements and specifications is often not enough. When clients actually see the artifact, the chances are they might not like it. Despite all the extensive talks you had with the clients, they might have formed an idea and imagination that is actually very different from your thoughts.
This is to say that to reduce software development costs and further reduce the number of iterations to figure out what exactly users want, an additional level of the agreement must be found beyond Ubiquitous Language. Creating a common language shared by all stakeholders and widely used in all verbal and written communications is of immense help to ensure that each word spoken is understood correctly and, subsequently, software specifications are correct.
Let us tell you this. However, that big talks are worth nothing, and to give clients a realistic and proper perspective of what you’re going to do, you should probably show some code. But remember, code also is much expensive to produce, and nobody likes the idea of writing code that might be thrown away if some assumptions made and not particularly resolved by specifications turn out to be false.
UX stands for user experience, and UXDD is a top-down approach to implementing whatever supporting architecture you underline or choose for the system. USED differs from most commonly used processes 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 clients sign off on wireframes and storyboards for each task offered through the presentation.
Why is a top-down approach better than a bottom-up one?
Over time, many great ideas have been first designed or drawn out on the paper napkins of some cafes. This is because hand-drawing is still a fantastic way to jot down ideas, whether it’s ideas about the top-level architecture of a system or the user interface the actors will use for their interactions. More often than not, clients have a tough time exaggerating what they want, but on the other hand, they are not expected to explain in full detail the experience they want. The development team should grab the key points and learn from fundamental processes to use them as per their natural character in software.
If you agree with this vision of the software world, you also agree that presentation is way more important than it has been in past decades. The term top-down is nothing new in software, and it is often used in the context of code. Professor Niklaus Wirth—the inventor of Pascal— was the first to coin and use the term extensively.
The point we want to make here, though, is architectural. Architecturally speaking, we dare say that in past decades we never applied any top-down design approach. Everything we did was done to build the system from the bottom up. It’s about time we consider a different approach to reduce development costs.
Foundation of the bottom-up approach
As we see things, we keep on designing and building software as we have done for at least the past 10-15 years. However, a lot has changed simultaneously, both in terms of client and server software and, more than everything else, in terms of the actual users’ expectations.
Assets of the 1990s
In the 1990s, the IT department in most companies was built around a huge powerful server that cost a lot of money and had to be used as much as possible. The server ran all the business logic and took care of all persistence tasks. On top of the server, you typically had a few, and far slower, personal computers acting as dumb terminals with just a friendly Microsoft Visual Basic user interface. More than everything else, though, in the 1990s, there was a mass of users passively accepting any UI constraints imposed on them by software engineers.
The presentation layer was just disregarded, and all the design efforts focused on getting the most out of that powerful server the company invested all that money on.
What’s different today?
One thing is more apparent than today: we live and write software in a totally new and different world.
Today we have an astounding number of advanced technologies and innovations and various client devices. This poses new difficulties for software architects and results in users actively dictating user-interface features instead of passively accepting whatever is offered. Today, and even more so in the future, a poor user experience might become a severe issue and undermine the software’s reputation. What you see happening for mobile apps—with many downloaded and soon dismissed— might become the norm for all applications.