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.
UX First
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.
More Than Coding 
Agree in general, but ðere is a reaſon ƿe are often are forced to diſcuß tools or architecture beforehands: it is becauſe ƿe arrive at a ſituation ƿhere inadequate tools ſuch as MS Ƿindoƿs or MySQL are already beiŋ decided upon.
Nice article, I tottally agree with you.
Terrible advice and flawed analogy. Designing UX first is like “OK, we’ll have roof build of gold and platinum. I have no idea how we’re going to build the wall that will support all these sparkles, but I promise I’ll figure something out. Look, sparkles! So shiny.” and then you’ll end with gold roof and concrete walls hundreds meters wide. That’s what comes from UX first. Complete waste of time, energy and failure.
If the business decides that a house with a shiny roof is what’s needed to compete in the marketplace, then what’s the problem? That’s a vision for a new product, and the developers will have the responsibility of creating an architecture that can support it and then use the right tools to then build it.
The developers can (and should) negotiate with the product owners at the start of the process if the vision for the product is totally removed from reality and would lead to a terrible product. But at least both the business and the technical sides had their input into the process at the right time: the start.
Also, “a roof built of gold and platinum” and sparkles is UI, not UX.
Form over function.
Doesn’t sound like a good way to build robust software. I agree that UX is important, but data model should come first in most cases.
(Do own a Mac?)
A piece of software has to ultimately meet the requirements. If you haven’t adequately defined them, no amount of form is going to make your software effective.
A common mistake is to think that UX refers to the UI. UX actually lays down what the customer needs and expects, which is what you need to base your code around.
Interesting read – thanks.
IMHO, UX and the backend should be to a large degree separate. For example, it’s the responsibility of the database to store the data in the most effective way – it shouldn’t be affected by how the UX will work. The decision to use traditional (web-traditional) MVC or some sexy client-side tech should not affect whether you want a RDB, a No-SQL DB, a graph DB etc – the data should be the only thing affecting this decision.
Saying that, I agree that the UX is probably the bit of the application that in reality will make it succeed or fail. Scaling is essential, but you can scale badly (eg. Twitter Fail Whale) but if your UX is clean and works, then you’ll probably get through it. If you choose the wrong DB you can always change it (a hassle though it might be), but if no-one can work out how to use your app, then what’s the point. So in that degree, I agree with your premise.
In a tiny team, then work on the UX together then work on the backend – great. But if you have a bigger team, then I don’t see any real need to wait for the UX to be designed before the DB guys or the API guys get on with making stuff.
There’s one flaw with your analogy. The laws of physics dictate the order in which things must be done when building a house. No such laws exist for software systems so there is no “natural” or “right” way to build a software system.
Good article. More please. #hatersgonnahate
Agree to disagree. UX is important step in designing a product. But as a product owner you define the core as business function (which may be intertwined with UX or not). There are a plethora of products that are build upon business function alone and are successful. May be you can specify further that there are types of products that must be created with more focus on UX than usual. In any case product design is better implemented with balanced approach, you cannot create a product without available tools and technologies at hand. Balanced approach requires a lot of quantitive data to be analysed and then applied to design process and architecture. As a designer my self I understand the sentiment towards UX, but as a developer with experience I cannot put aside implementation processes. Thanks for the article.
If you by UX mean user experience, instead of user interface, then I totally agree. If not, then I disagree. The difference is that user experience starts with problems/issues the user wants to solve. How they feel before it’s solved, how they feel afterwards. What they perceive the solution to be, how can they think about the solution in a practical manner for them (that’s such an important question that’s almost never asked by developers/PMs using themselves as proxies for the customers).
The user interface is an answer to the questions raised above. If you don’t know what those questions are, and have a less than firm idea to what answers to them look like, then the user’s experience will be awful no matter how nicely it is designed.
I’m a fan of user centric design, whether it’s domain driven design or a UX practice. I’m a Technology person too.
One thing that is dangerous about the above is from a top down perspective, UX folks don’t always know the possibilities and capabilities of tech (or feel they don’t need to) which can hinder the design.
As well, UX doesn’t always know how users prefer to work with the data for anything beyond mild and simple use cases. Results in a lack of depth, or too much depth.
It’s far more reasonable for creators (tech), designers and UX to be at the table from the start instead of any one group trying to abstract away the other in some sort of hierarchical or structural land grab.
If this doesn’t seem realistic, imagine if tech folks can learn to work with any type of detail easier than design folks can learn to code. The power will converge in developers who can design, and designers who can develop,
Amen! Thinking about the UX – the actual USER EXPERIENCE should be first, always. And driven by an understanding of the market, the user’s REAL needs, and all of this takes thought before jumping into what seems ‘cool’ like picking out a framework, or hot new db to try. A product developed with UX and needs first will be inherently cleaner, easier to maintain and support compared to one where ‘well engineering built this so now lets put a count of filler and paint on it…’
So, lot’s of formal education in software design. Design starts with requirements, typically business requirements. Then you can go with system architecture to suss out what business units get involved. Then once it lands in our court we come up with software requirements. Then there are all kinds of iteration on the requirements. Once that is done rapid prototyping, mock ups, and story boards are some of the tools that can be used to do a first run of UI/UX and usability studies. Once there are initial UI/UX scripts then they can be part of the process for initial QA test plans. This is the formal training I received in college. The reality is that management wants it and wants it now. The steps to formally create software are short circuited and everybody ends up winging it. Engineers rarely see the formal process end-to-end and bad habits become assumed expected habits. This is why most engineers are comfortable with Unit testing as the only testing. Testing always get short changed. Now we call that move fast and break things. This is not a case of engineers not wanting to do the right thing, but being conditioned that winging it is the expectation.