Hacking: Always Design the UX First(blog.systemizer.me)
blog.systemizer.me
Hacking: Always Design the UX First
http://blog.systemizer.me/2012/06/hacking-always-design-ux-first.html
35 comments
I strongly disagree. Of course I understand what you mean about proof-of-concept - your analogy of testing the engine is a good one. But think about wher the engine is to be fitted: if the UI is not well-specified, then the best engine in the world will only help you crash or blow things up faster.
you can't build good data structures until you have a clear idea of the information you want to gather and manipulate for the task you propose to solve, and often that involves going to other people in a specific market and asking them how they do things. I have lost count of the number of software packages I've looked at and asked 'why is X so awkward' only to receive the reply that it 'had to be that way' because of something on the backend. This is what happens when you build data structures that are half-adequate to the task at hand and then have to have other things shoehorned into them.
you can't build good data structures until you have a clear idea of the information you want to gather and manipulate for the task you propose to solve, and often that involves going to other people in a specific market and asking them how they do things. I have lost count of the number of software packages I've looked at and asked 'why is X so awkward' only to receive the reply that it 'had to be that way' because of something on the backend. This is what happens when you build data structures that are half-adequate to the task at hand and then have to have other things shoehorned into them.
Well, funny enough, I am one of those guys who is equally comfortable doing mechanical, electrical and software engineering. In all cases, the "beautification" of the product happens after the underlying principles, data structures, circuit fundamentals, loads, thermal requirements, etc. are well understood and have gone through many prototyping and testing phases. I am not talking about minimum-viable-product stuff here.
Yes, if the goal is a minimum-viable-product type web solution, by all means, make it pretty and fake the rest until you see enough traction to figure out if there's a real business.
For nearly anything else, the internals need to be well understood before it makes sense to do anything else. I can't think of one mechanical design I've done where I spent a ton of time figuring out color, size, shape and location of buttons and knobs before fully understanding what needed to go inside the box, what the electronics was going to look like, communications protocols, power supply requirements, environmental requirements, etc.
So, yes, if I was going to design a car I'd start by selecting an engine, drive train and suspension components and then designing the of the vehicle rest around it. You'd fit artists concepts and renderings to the realities of the underlying mechanics. It then becomes an iterative process where you push and pull and make adjustments to both the artistic expression and the technical realities of the design in order to converge on a product that can be released.
Let me state the obvious: These analogies are all imperfect.
Yes, if the goal is a minimum-viable-product type web solution, by all means, make it pretty and fake the rest until you see enough traction to figure out if there's a real business.
For nearly anything else, the internals need to be well understood before it makes sense to do anything else. I can't think of one mechanical design I've done where I spent a ton of time figuring out color, size, shape and location of buttons and knobs before fully understanding what needed to go inside the box, what the electronics was going to look like, communications protocols, power supply requirements, environmental requirements, etc.
So, yes, if I was going to design a car I'd start by selecting an engine, drive train and suspension components and then designing the of the vehicle rest around it. You'd fit artists concepts and renderings to the realities of the underlying mechanics. It then becomes an iterative process where you push and pull and make adjustments to both the artistic expression and the technical realities of the design in order to converge on a product that can be released.
Let me state the obvious: These analogies are all imperfect.
A good user experience isn't 'making it pretty' or 'beautification' – this is 2012, I thought this was repeated enough.
You make good points, and I do agree that multi-platform applications require a general enough server-side interface for many different types of clients.
However, you're still going to initially design your application based on a single interface, whether that be an iphone, browser, or tablet. While the implementations will differ, the UX between all the clients should be consistent.
In the article, I put UI ahead of CRUD because I believe the UI is closer to the UX and better helps you achieve your UX. And by UI, I mean a very very simple user interface. Hold back your creative artsy mind and just make sure you have the actions on the page.
thanks for the comment.
However, you're still going to initially design your application based on a single interface, whether that be an iphone, browser, or tablet. While the implementations will differ, the UX between all the clients should be consistent.
In the article, I put UI ahead of CRUD because I believe the UI is closer to the UX and better helps you achieve your UX. And by UI, I mean a very very simple user interface. Hold back your creative artsy mind and just make sure you have the actions on the page.
thanks for the comment.
There's a third scenario.
Leave the data model alone, and stop thinking about the UI. Do some real design.
Consider a simple example - registering a user account.
Assume the product vision statement calls for a thick client desktop application that synchronises data to other desktop clients via a server. To use the sync service you need an account. On the client, you put up a form that asks the user for a user name and password. Easy. What happens when the call to the server is made to register that account?
Does the UI just lock up until the call returns? Does the UI remain responsive? Does a responsive UI allow the user to cancel the request? Is the technology chosen to build this thing even capable of asynchronous service calls?
When the data is sent over the wire, how is it protected? When it hits the server, how and where is the password stored? Is the request logged? Will server logs be of use to anyone? What error conditions are checked on the server, what corresponding messages are sent back to the client, and how are these communicated to the client? Is there a retry button the user can hit when it bombs? Should the client use a database/temporal cache/config file to store the user name and password in case the server is unreachable?
That was a very simple use case. [Edit] My point is that those questions demonstrate that the data model as well as the UI might radically change based on other design decisions you should be making first. To answer those questions you need to do some design work.
Design work means analysis to get business, user, system, and operational requirements.
Then you need to think about availability, backup and recovery, capacity, communications, deployment, end user support, data migration, monitoring, performance, pilot program, security, system support.
It's called an architecture.
[Second edit] The agile police is probably going to jump on me for what I wrote. Let me pre-empt that by adding that even little web apps have what may appear to be very simple use cases that can bite you in the ass.
Leave the data model alone, and stop thinking about the UI. Do some real design.
Consider a simple example - registering a user account.
Assume the product vision statement calls for a thick client desktop application that synchronises data to other desktop clients via a server. To use the sync service you need an account. On the client, you put up a form that asks the user for a user name and password. Easy. What happens when the call to the server is made to register that account?
Does the UI just lock up until the call returns? Does the UI remain responsive? Does a responsive UI allow the user to cancel the request? Is the technology chosen to build this thing even capable of asynchronous service calls?
When the data is sent over the wire, how is it protected? When it hits the server, how and where is the password stored? Is the request logged? Will server logs be of use to anyone? What error conditions are checked on the server, what corresponding messages are sent back to the client, and how are these communicated to the client? Is there a retry button the user can hit when it bombs? Should the client use a database/temporal cache/config file to store the user name and password in case the server is unreachable?
That was a very simple use case. [Edit] My point is that those questions demonstrate that the data model as well as the UI might radically change based on other design decisions you should be making first. To answer those questions you need to do some design work.
Design work means analysis to get business, user, system, and operational requirements.
Then you need to think about availability, backup and recovery, capacity, communications, deployment, end user support, data migration, monitoring, performance, pilot program, security, system support.
It's called an architecture.
[Second edit] The agile police is probably going to jump on me for what I wrote. Let me pre-empt that by adding that even little web apps have what may appear to be very simple use cases that can bite you in the ass.
I go to MIT and have taken graduate courses in OS design, database design, and distributed systems. I am more than aware of the issues of byzantine errors, fault tolerance, and replication, etc; however, my post is not about that. My post is about how to approach "hacking" a minimal viable product together and guidelines for making that process efficient. The issues that you present are not relevant to this post and can be abstracted away for this context.
If I had to guess why your response was downvoted (wasn't me) I'd say that it's because you didn't make this clear in your post. That said though:
In my opinion(!!) hacking out a minimum viable product (MVP) should still go through an up-front design phase. Before any UI work or data modelling is done.
Anwering those questions will help determine what that MVP will look like, and whether it will annoy users or have them wanting more. Apart from the obvious technical benefits it provides direction, motivation, and (one scenario) if you're looking for funding will help you articulate not just the product vision, but the technical roadmap, risks and, above all, provide a reasonably-informed estimate that will drive your financial models.
It's awesome that you go MIT.
In my opinion(!!) hacking out a minimum viable product (MVP) should still go through an up-front design phase. Before any UI work or data modelling is done.
Anwering those questions will help determine what that MVP will look like, and whether it will annoy users or have them wanting more. Apart from the obvious technical benefits it provides direction, motivation, and (one scenario) if you're looking for funding will help you articulate not just the product vision, but the technical roadmap, risks and, above all, provide a reasonably-informed estimate that will drive your financial models.
It's awesome that you go MIT.
There is a huge difference between designing the experience (UX) and the designing the interface (UI). I don't know if you got them mixed up, but I don't think the title suggests doing the interface design first, but the experience.
This can be done in writing on a piece of paper.
This can be done in writing on a piece of paper.
I agree with you, but I believe it is different with experience. If you are new then you might think aobut the UI level because it is easier to visualize what the web program is going to do. If you have been making web programs forever, I find it easier to think at the database level and create all of the tables/fields. Then I think about how the interface visually is going to handle the data.
I would agree, if you already understand the business problem. However the UI is often the only thing you can discuss with the client; few clients are going to be able to react to a data model but most can engage in a discussion based on a proposed UI design, which can then help you, the analyst, understand what you need to capture in your data model.
Always be cautious of advice that starts with the word "always". The UX you design first might preclude an innovative approach that you would have discovered if you had just started coding first without a plan.
I concur. It's much easier to plug in functionality and DB objects into a finished UI/UX than the other way around. Also, it allows the hacker to just work on the core functionalities instead of worrying about how their code is supposed to output to fit into an unpainted canvas.
Obviously if you're working on an API, this doesn't apply - but you'd be surprised at how fast the hacking sprint can get when you know exactly where to plug your code into.
Obviously if you're working on an API, this doesn't apply - but you'd be surprised at how fast the hacking sprint can get when you know exactly where to plug your code into.
I'd probably recommend having an example app that uses the API anyways :)
And the API itself is UX for developers...
If the main problem you are solving is a usability problem, a domain-specific language syntax, for example, or maybe a new photo-sharing app that's better than all the other photo-sharing apps, then the top-down UX-first approach is better. If you are mainly trying to solve anything else, it's probably better to focus on that first and make sure the data models, APIs, algorithms, or other key features are solid.
An exception to this could be when you just need to get something up and running for morale reasons, so you can begin iteration. (Although in that case I would still argue that focusing on the UX isn't critical)
An exception to this could be when you just need to get something up and running for morale reasons, so you can begin iteration. (Although in that case I would still argue that focusing on the UX isn't critical)
Speaking of UX, this is what that page looks like when JavaScript is disabled.
https://img.skitch.com/20120604-e4x8dgp8u82akj7ngmyhywbtdb.p...
https://img.skitch.com/20120604-e4x8dgp8u82akj7ngmyhywbtdb.p...
Sorry about that guys. I just started using Blogger's new blog theme. I assumed they would account for javascript-disabled clients, but I was wrong. I'll fix that asap.
thanks!
thanks!
So... don't do that then. My browser is set to deny requests to other domains by default, so the whole page is blank for me. But I'm not complaining about it because that's my choice.
Edit: oddly, Readability works fine.
Edit: oddly, Readability works fine.
When I tried to view it from Instapaper on my phone I also got a blank page.
Try it on the iPad.. The UX completely breaks.
Designing the UI first also boosts morale b/c it gives you a tangible sense of progress, and you get to see what the end product looks like.
Yes, but be wary of showing a prototype UI which works as if the functionality/back-end is also working. Even if you stress that its not, the client will understand that the functionality is already working if they can see it, and won't understand what you're doing afterwards or why the back-end is taking so long. Be especially careful with making assumptions about complicated functionality and back-ends, as they are difficult to estimate and clients grow very frustrated after they've already seen everything "working".
I'm not afraid of a temper tantrum, it shows the client cares. Showing a basic UI that was generated by the use cases will confirm that you understand the client needs, reduces miscommunication and clearly highlights the feature creep you should be charging for. It helps the client sell the project to whoever she reports to. It's easier to change a UI and it's a stronger emotional lock-in for the client (so she doesn't cancel). Win all around!
The authors makes it sound like after designing the UX, the implementation will become trivial. I think this is a bit naive because most serious applications go through many iterations of UX. Some of these changes will be small and not require significant re-plumbing, but others will necessitate a lot of behind-the-scenes churn.
My point is that it's better to design the plumbing of an application with some longer-term considerations than just "what do we need to implement that UI wireframe."
Minimal viable products are cool and all, but let's not use that as an excuse to write something that will need to be thrown out wholesale to add that big traction-building feature.
My point is that it's better to design the plumbing of an application with some longer-term considerations than just "what do we need to implement that UI wireframe."
Minimal viable products are cool and all, but let's not use that as an excuse to write something that will need to be thrown out wholesale to add that big traction-building feature.
Wanted to jump in on this. Like any problem, the answer is "it depends". If you are building an application that relies on having an extremely slick UX, you should probably start there. If you're creating an app that you want to be a workhorse or relies on a highly experimental feature, start at the implementation level.
With that said, I do feel like teams of pure programmers have a tendency to overlook the UX in favor of diving right into the code. The article is a great reminder that it takes more than wonderful code to solve a problem. In fact, the less code the better.
With that said, I do feel like teams of pure programmers have a tendency to overlook the UX in favor of diving right into the code. The article is a great reminder that it takes more than wonderful code to solve a problem. In fact, the less code the better.
I immediately dismiss any posts claiming to know the superlative of anything -- best/worst, always/never, dead/alive.
Yet, somehow, I've manage to consistently hack successful things.
My advice: Avoid linkbait articles like this, and instead spend the time actually building something. Really, it truly is that simple: Build something. In any order. With any technology.
Yet, somehow, I've manage to consistently hack successful things.
My advice: Avoid linkbait articles like this, and instead spend the time actually building something. Really, it truly is that simple: Build something. In any order. With any technology.
For me the UI should be just one example of how the API of the model can be used, the model is the engine, the UI is the tool that the user manipulates to move the engine.
I guess there are different schools.
I guess there are different schools.
Importantly, it's also likely to be the first example, and failing at the outset will make it difficult to gain any sort of traction.
I need to learn from this. I'm usually too excited to start turning out some code, and I almost always end up at a dead end a few weeks later (talking about personal side projects).
The site doesn't seem to load.
Within the constraints of a hackathon-type scenario, in general I would hypothesize about the expected user interactive results (the experience) model my data, establish the basic CRUD and wrap the UI around that, tailoring the experience to what the actual user outcome will be. If you do it in the order listed in the post you'll end up spending too much time with a UI and later having to model the data around it. That's backwards.
tl;dr: hypothetical use case, data model, CRUD, UI, test for results.
tl;dr: hypothetical use case, data model, CRUD, UI, test for results.
If you're designing the UI first, you're not "hacking" anything.
In my view you must think in terms of data models / data representation first. Then you move on to CRUD. At that point you might move into some of the functionality above CRUD and other app mechanics (for example: login, authorization, verification, support interaction, etc.). At this stage, if we are talking about a web project, the UI doesn't need to look any prettier than a Craig's List page.
Once that reaches flight altitude (meaning, that the basics are working) the UI can become the focus.
This becomes particularly true when you consider multi-platform applications. Say you have an app that needs to run on the web, mobile-web, as well as various phones and tablets. If the UI is first, which one? They are bound to be different. If you focus on the UI first you might do things that skew the model to suit a particular platform.
I you believe in MVC then you ought to be able to separate the three through specifications and marry them once each has reached a certain level of compliance with said specifications. Of course, there are difference that contrast a solo developer/designer vs. a multi-person team.
I want to see the engine sputter, backfire and pop before I try to optimize anything and make it pretty (UI).