
Hacking: Always Design the UX First - systemizer
http://blog.systemizer.me/2012/06/hacking-always-design-ux-first.html
======
robomartin
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).

~~~
anigbrowl
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.

~~~
robomartin
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.

~~~
lovskogen
A good user experience isn't 'making it pretty' or 'beautification' – this is
2012, I thought this was repeated enough.

------
brlewis
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.

~~~
skbohra123
Fittingly, your advice is also starting with always.

~~~
dllthomas
I assume that was the joke.

------
kappaknight
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.

~~~
scottschulthess
I'd probably recommend having an example app that uses the API anyways :)

~~~
dllthomas
And the API itself is UX for developers...

------
Goladus
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)

------
jdludlow
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.png)

~~~
systemizer
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!

------
AznHisoka
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.

~~~
kylebrown
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".

~~~
ilkandi
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!

------
ighost
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.

------
loudin
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.

------
anon-for-now
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.

------
jorgeleo
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.

~~~
iMark
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.

------
amishforkfight
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).

------
sktrdie
The site doesn't seem to load.

------
jsavimbi
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.

------
eswangren
If you're designing the UI first, you're not "hacking" anything.

