Imagine you are building your dream house. Would you trust a general contractor who talks like this?
First, we’re going to pick out the material for the kitchen counter and the glass for the windows. Let’s just guess the amounts of each to buy for now.
Then we’ve got to buy some of that new concrete everyone’s been talking about. I suppose a truckload will do it for now, but we could always order more later. I just can’t wait to try it out!
After putting the beams in place we should decide how many floors the house should have. And right at the end we should decide what style the house will be. Sometime before you move in we should get planning permission, and I’ll probably contact an architect for some drawings after you’ve settled in.
It sounds ludicrous because there’s a well-established method for building houses, and it’s based on common sense. You start with a vision, get a set of plans, pour a foundation, build the framework, fill in the internal stuff, and finally finish all the little details.
Putting any step out of order would cause complete chaos. Finishing the walls before the electrical would mean you’d have to punch holes in all your walls in order to run wires around the house. Cleaning it before it is completely finished would be a wasted effort given the amount of dust builders cause while they work.
However many coders build their systems backwards. They become enamored with the latest whizz-bang framework or charmed by the reportedly speedy performance of the newest database. And they lead their thinking with those choices as they build new features, whether those technologies are appropriate or not.
More importantly, using a technology-first design typically means that the user experience (UX) will be left until last. And if you put your users last in your order of priorities, it will unfortunately be very evident in your system’s lack of usability.
The first order of business in application design is deciding what its users will experience. This should be a high-level vision sketched out on paper or in simple digital mockups, and it should express the flow of the system from the user’s perspective.
It doesn’t matter if you’re building a web application for senior citizens or a system-level tool for serious computing nerds. The UX must be designed first.
Type of System
Your First Thought Should NOT Be…
Your First Thought SHOULD Be…
|Online music player||“I’m going to design the database schema!”||“Let’s design the UX”|
|Social media plugin||“Let me start hacking around with some online social media APIs!”||“Let’s design the UX”|
|Multiplayer Game||“SuperFastDB is apparently really scalable, I’ll start testing it today!”||“Let’s design the UX”|
|Virus Checker||“I’ve been dying to write a new virus scanning algorithm, so I’m jumping right into that!”||“Let’s design the UX”|
|GPS Device||“I’m going to research the latest in OLED technology right away!”||“Let’s design the UX”|
Then Comes The Architecture
Once the UX has been designed and the vision of the system has been defined, an architecture should be laid out to make sure that the code that eventually gets written will actually meet the needs of the users. The choices made in the UX design radically shape and inform a system’s architecture.
A good UX design will cater for less obvious things that might be part of the overall user experience. A well-written specification might include requirements such as “the overall load time for page loads must be less than 200 msec” because the designers know the consequences of slow page load speeds. It might also call for close-to-zero downtime, so the architecture might end up requiring a multi-datacenter deployment.
Last But Not Least, The Tools
Now it’s finally playtime! Once the UX has been defined and the architecture has been laid out, the process of picking the right technologies, frameworks and libraries can begin. The crucial point is that now the tools are being chosen with the UX and architecture in mind, so any tool that doesn’t fulfill the needs of either can be quickly disregarded.
This Does Not Mean “Waterfall”
If you think that this design sequence requires an outdated Waterfall-like approach to accommodate it, think again! This is completely appropriate for Agile development. The implementation of a whole new product, an epic or even a single user story should follow the UX -> architecture -> tools sequence. When beginning the development of a product or epic, spikes should be used to design the UX and the architecture. And individual user stories should include enough details for the engineer to know what the UX for that story should be once it is fully implemented, and the engineer should also estimate enough points to cater for architectural planning to be done once work on that story begins.
Tools are great fun to research and to experiment with. Programmers love discovering new ones and finding “The Next Big Thing” in the framework jungle, and having lots of tools at your disposal is wonderful when the time comes to build a system that satisfies the UX and the architecture. Just don’t begin the entire design process with them. So remember: UX first, then architecture, then tools.