from Hacker News

Hacking: Always Design the UX First

by systemizer on 6/4/12, 3:37 PM with 35 comments

by robomartin on 6/4/12, 5:03 PM
I disagree with this. Think of the basics of the UI if you'd like, but this idea of creating it first might only apply to a narrow project definition.
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).
by brlewis on 6/4/12, 4:16 PM
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.
by kappaknight on 6/4/12, 5:39 PM
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.
by Goladus on 6/4/12, 8:53 PM
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)
by jdludlow on 6/4/12, 3:58 PM
Speaking of UX, this is what that page looks like when JavaScript is disabled.
https://img.skitch.com/20120604-e4x8dgp8u82akj7ngmyhywbtdb.p...
by AznHisoka on 6/4/12, 4:41 PM
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.
by ighost on 6/5/12, 12:17 AM
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.
by loudin on 6/5/12, 11:20 AM
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.
by anon-for-now on 6/5/12, 1:36 AM
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.
by jorgeleo on 6/4/12, 4:08 PM
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.
by amishforkfight on 6/4/12, 4:09 PM
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).
by sktrdie on 6/5/12, 1:20 AM
The site doesn't seem to load.
by jsavimbi on 6/4/12, 5:44 PM
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.
by eswangren on 6/5/12, 12:31 AM
If you're designing the UI first, you're not "hacking" anything.