

Don't look for a UX guy, be a UX guy - merijn481
http://blog.factlink.com/post/23308427848/dont-look-for-a-ux-guy-be-a-ux-guy

======
ericclemmons
Often I see UX boiled down to this quote from the article:

"To build a great UX, one has to step back and think about what’s most
important, try to come up with the most simple and shortest path to get there,
build, analyze what works and why(not), measure, test, rinse, and repeat."

This is the "left-brained" part of UX, while there is the forgotten "right-
brained" portion, which is typically based on the psychological impact of
copy, typography, and visual polish.

For example, I worked for a company that wanted to remove all "distracting
copy" from the form page so that the submit button was above the fold (and
fewer distractions, etc.). We ran multivariate tests swapping copy, removing
copy, rephrasing copy, you name it, to figure out what our visitors were
actually responding to.

Our original "assurance copy" (letting the user know what the information is
for, what's going to happen next, etc.) more than doubled our average time-on-
page metric. However, our conversion took a ~27% _drop_ when we removed it
entirely, and incrementally better the more copy we had.

The users that _did_ convert spent half the amount of time on the page (they
were already committed to purchase by that point), but the rest of the users
obviously needed assurance in the process, not necessarily the cheapest
process.

~~~
peetahb
_This is the "left-brained" part of UX, while there is the forgotten "right-
brained" portion, which is typically based on the psychological impact of
copy, typography, and visual polish._

What you're referring to is the UI, the aesthetic design, layout and features
that lends itself to an effective UX. They work hand-in-hand; like the OP had
stated (paraphrasing), coming up with the simplest and shortest path to your
goals that works, is important for the UX, and knowing your goals and how you
want to reach them will help guide the UI.

It's tough to find someone who can focus on UX or to find someone who can
translate the UX to a great UI. But it's the toughest to find someone who can
do both. It's even harder to become that person.

------
zavulon
> I think the greatest companies of the next few years will be build by teams
> that consist of people that can program AND can do UX.

I couldn't disagree more. I have never met anybody who can program AND do UX
_well_. Maybe there are very very rare exceptions, but these two skills are
pretty much mutually exclusive.

First of all, you need completely different modes of thinking while coding and
while doing UX. Left/right brain, and all that. But more importantly, to be a
good UX person, you need tons of training - design, marketing and psychology
being three main areas. To be a great programmer, you need completely
different set of training. Both UX and programming require single-minded
attention, dedication and years to master.

To expect someone to do both of those things well is not only unrealistic, but
plain WRONG.

~~~
gmurphy
It's hard to meet people like this because of attitudes like this. I have
three designers on my team who are also world-class engineers, yet they often
don't advertise themselves as such because they run into the "well if they do
both they can't be good at either" attitude.

No-one bats an eye when an engineer also turns out to be a fantastic musician,
or when an engineer drives great product decisions, yet somehow being able to
code and understand design is an impossibility?

We're here to build great things - code and design are mutually-beneficial
skills in your toolbox; your brain is not zero-sum.

~~~
zavulon
I would agree with you if these were _complimentary_ skills we're talking
about. However, programming and UX design are almost contradictory.

For programming, you need a mathematical inclination, attention to detail,
willingness to sit down and focus on one concrete task at a time, etc. For UX
(and any kind of other) design, you need more an ability to _create art_ \-
paint with broad strokes, look at the big picture, etc.

This is my opinion, YMMV, feel free to disagree, etc

~~~
mtjl79
No, you're incorrect.

UX (User Experience) is about designing exactly that - an experience. It's
about being extremely detail oriented, mathematical inclination (sifting
through metrics, a/b testing data, CTR, bounce rates, etc.), willingness to
sit down and focus on one concrete task at a time, sifting through hours of
user video seeing how people interact with an application and then finding
solutions to make the UX more smooth. Sound familiar to what you wrote about
your "programmer"?

Not so different after all it seems.

EDIT: Everyone seems to confuse UI design with UX design. They are very
different, and in some cases are different job descriptions.

~~~
phamilton
UX is about empathy. Understanding how other people think and the emotions
they feel. All those tools you mention are metrics to keep score, but without
an understanding of how your users think you are playing a fun game of guess
and check. Sure with enough iterations and metrics you can figure out
anything, but your users won't give you that many chances. Someone who can get
the initial design in the right ballpark and use metrics to fine tune it is
your UX guy. As I programmer I really struggle putting together a viable
initial UX, and I don't think I'm unique in that struggle.

Quite frankly, it's because I think very differently from most people and have
trouble understanding their thought process. I'm not introverted or especially
socially awkward or any of those engineering stereotypes. Everything from my
ability to creatively approach problem solving to my subtle dry sense of humor
is because of my different way to think about things. But when I need to think
like everybody else, I just can't do it. That's why I need a UX guy.

------
raverbashing
You can try, but it's tough

Seeing Google try different shades of blue automatically, just goes to show
that _they don't know what they are doing_

"To build a great UX, one has to step back and think about what’s most
important, try to come up with the most simple and shortest path to get there,
build, analyze what works and why(not), measure, test, rinse, and repeat."

This is very important. But get this: measuring and refining _won't_ fix big
errors.

So work with a designer and don't BS him trying to do "live genetic
programming" your site with your A/B tool.

~~~
badclient
_Seeing Google try different shades of blue automatically, just goes to show
that they don't know what they are doing_

Why does that show that "they don't know what they are doing"?

~~~
raverbashing
Forgetting for a moment all the theory of color and contrast /equilibrium in a
design:

1 - different people see different shades (difference in monitors)

2 - Unless there is a glaring problem with the shade of color chosen (like
something most designers wouldn't approve), changing shades is one of the
least important areas of improvement possible

3 - The current redesigns of GMail / G+ / GReader (among others) are very
showing that Google is thinking like "engineers" and not like UX experts

~~~
badclient
(1) Can't that be accounted for in some manner, especially when you have so
much data? Typically when I design tests at work, it is not unusual to add
many rules and exceptions to make sure the data is as accurate as possible.

(2) This is where it becomes tricky. You have to understand that these
decisions are made at a very local level by small teams with specific
goals(for example, "bump revenue from sidebar links by x%"). Also, it is
unrealistic to suggest that a company the size of google can _only_ work on
super big items when at Google's volume, small improvements can add up and
result in hundreds of millions in additional revenue.

(3) Not a fan of the new gmail but using their blue shade experiment as
supporting evidence for why their design sucks isn't very powerful.

~~~
raverbashing
1 No, you really can't account that. You can't account for people's eyes as
well. You may make a guess (maybe on display resolution) which is not precise
at all.

2 Google does an can certainly work with whatever they want, but they should
try the big improvements first. Their work with page loading times is great,
and that has been shown to correlate with earnings. But trying to tune the
shades when there are more important things to be worked is pointless

3 It goes to show they don't understand design. In some aspects they do (like
GMaps) but it seems to be declining

------
cek
"To build a great UX, one has to step back and think about what’s most
important, try to come up with the most simple and shortest path to get there,
build, analyze what works and why(not), measure, test, rinse, and repeat."

This is true, but in my experience, the best UX people are even more excellent
at figuring out what is NOT important and getting rid of it (or not investing
any time in those things at all).

Also, just as the "learn to program" meme does not, and can not, apply to
everyone, "be a UX person" does not apply to everyone. A significant part of
what makes great UX comes from the right-brain and some of us simply are
physiologically weaker there.

When I shifted my customer focus from developers to consumers in 1999, after
10+ years of building products, I made a conscious decision to become a "UX
guy". I spent YEARS working on that skillset. I even had some pretty strong
successes.

But I still suck, compared to my UX idols. I like to think I know good UX when
I see it, and I can guide others to do it, but when I'm on my own I struggle.

~~~
peetahb
_This is true, but in my experience, the best UX people are even more
excellent at figuring out what is NOT important and getting rid of it (or not
investing any time in those things at all)._

I believe that's what the OP implied when he stated _most simple and shortest
path to get there_ , simplifying the UX/UI is based on deduction, archetype
development and enough experience/knowledge to start off with a barebones
wireframe instead of a bloated mess. Loosely basing the method of delivering
an effective UX on Occam's Razor, a philosophy that states if you base your
decision on the path with _the fewest assumptions and thereby offers the
simplest explanation of the effect_ , that's usually the best route to take.

The most simple path is one that only relies on what's important to your goals
and skips all the bloated "data" and "ideas" that would hurt the UX.

------
gruseom
I think there's another factor. Even if you have talent for both programming
and UX, it's hard for the same person to do both those things well on the same
project. To program well you have to know the implementation inside-out. But
to do UX well you need to see the places where implementation complexity is
leaking through and confusing users. For that, it's helpful _not_ to know too
much about how the sausage is made (not sausage in general, but this
particular sausage). Once you are habituated to the internals, many details
will feel natural and obvious to you that are anything but natural and obvious
to users.

The best thing, of course, is to have the program's internal model and the
user's mental model be the same. Eliminate contradictions rather than hiding
them with complex mappings. ("Design is how it works".) But even then, there
will always be much complexity that the user should not have to know about.

------
ravejk
"to step back and think about what’s most important, try to come up with the
most simple and shortest path to get there, build, analyze what works and
why(not), measure, test, rinse, and repeat"

This is more than just UX - you're talking about product design, usability
testing, reviewing quantitative data, then reworking features & design (UX/UI
+ dev) - the whole thing.

Sounds like you're saying that the UX principle of, "being really persistent
in iterating and discovering what works" is essential to product - yea, agreed
- that's called working towards product market fit. That kind of analysis and
iteration is definitely good but not a novel idea.

Also, a suggested revision to title: "Don't look for a UX person, be a UX
person." There are women on here too, thanks.

------
emgreen
I find it slightly odd when developers resist caring about UX stuff, because
in lots of ways we're already doing it whenever we code. When coding we worry
about how to communicate the code's behaviour well, and whether it will work
intuitive for other devs. In UX's and in code we strive to build a shared,
useful and elegant mental model of the world. An API is just a UX for devs.

Apart from that, the ultimate purpose of our code is to serve the people in
the world. Well, kind of, often it's just for fun. But generally the aim is to
have a user using something; to exist as an entity in their lives and minds.
Surely this means studying the user doing their using is just inherently
fascinating? (If a dev codes in a forest, and no-one is around to use it ...)

I'm all for specialist UX folk, if resources can accommodate, they've put the
time into their discipline, and will obviously do a better job than those who
haven't. But when resources don't stretch, developers' brains won't explode if
they start thinking about UIs and UXs. There's enough transferable skills
there (methodical approach based on evidence, iterations, model building,
communication), that I think it's something a lot of devs could get passably
good at and enjoy without diverting too much energy away from their principle
specialisation. In fact I've found that my experiences with UX stuff has
improved my dev work.

------
rmb177
After seeing yesterday's Show HN post on Habit List,
<http://news.ycombinator.com/item?id=3998894>, this post really hits home. I
have a similar app in the store and their UI/UX is just at a higher level than
mine. It's so much easier to focus on the implementation details and not give
the UI/UX the attention it deserves. Especially when you're much more
confident in your programming knowledge than your design knowledge.

------
maigret
Said shortly: if you want to build a great product, you have to really
understand at each level what makes a great product.

------
CookWithMe
"To build a great A, one has to step back and think about what’s most
important, try to come up with the most simple and shortest path to get there,
build, analyze what works and why(not), measure, test, rinse, and repeat.
Sounds a lot like B doesn’t it?"

Sounds a lot like anything you can iteratively improve. Could also be applied
to marketing, cold-call-sales, making a great coffee, ...

------
WiseWeasel
Just as importantly, if you're a UX guy, you'll have a much harder time honing
your skills and convincing others that your solution is right without some
basic graphic design and coding skills, at least enough for prototyping.

------
its_so_on
So, let me quote a bit of this submission, add some facts, and then take this
to its logical conclusion.

> _The current meme going around Silicon Valley and startup land is that any
> founder needs to be a technical founder and be able to program. Don’t look
> for a technical co-founder, be a technical co-founder. Even more, every
> employee at an internet startup needs to be able to program...For those who
> are all-in on these ideas, I would like to raise the bar and say: don’t look
> for a UX co-founder, be a UX co-founder. Don’t look for a UX guy, be a UX
> guy_.

So much for the quote, and the amount the author wants to raise the bar by.
Fair enough.

But why not raise the bar to the top?

Instagram had 13 employees when it sold for a cool billion. (Thanks, Gabriel
Weinberg. [http://www.gabrielweinberg.om/blog/2012/04/how-many-
employee...](http://www.gabrielweinberg.om/blog/2012/04/how-many-employees-do-
you-have.html))

So, why not raise the bar to the top: single founder, no employees.

Let's say there is no aspect of founding your business that you can't get down
to 30 hours per week by that role. If you are ready to commit up to 120 hours
in an _exceptional_ week (7 hours of sleep every day, but otherwise get up and
work), in what way should you not be ready to fill up to four cofounders'
roles?

Raise the bar? Why not do it all?

Here is one recipe.

Role 1: (30 hours) Tuesday, Thursday, Friday, 8-6. This is business
development, including networking, scoping out employees, liaising,
negotiating terms, finding a scalable business model, doing market and product
research, finding competitors and seeing what features they have, talking to
users. While the company is very small, you also do customer service. You
don't necessarily have to have business experience, but you should have been
involved in a small company that expanded greatly or closed a round while you
were on board.

Role 2: (30 hours) This is pure uninterrupted coding, Monday, Saturday, and
Sunday, 8-6. You should be a full-stack developer well-versed in databases,
cloud services (e.g. amazon), front-end and back-end languages, version
control, etc. Role out the features that you yourself scope out above and
below (role 1 and role 3), or from actual mockups in photoshop that you design
Wednesdays or occasionally (see role 3) tweaked betwen 7-11PM the night
before. Liaise with talent that business development (you on Tuesdays,
Thursays, and Fridays) throws your way. Work from mockups you yourself create
(Wednesdays and some late evenings). Of course, you have 10 years worth of
coding experience and are an expert in Git, Python, PHP, Javascript,
databases, etc, and hopefully a couple of fully coded Android and iOS apps
that you have done by yourself.

Role 3: UX and UI. Wednesday, all-day. (Meaning 7-7, though this is creative
work and does not have constrained output, can include showing work to others,
etc). This includes a break, thinking deeply about what you're really doing,
looking at other web sites, and then laying out in photoshop the UX and UI
that you will be coding up during the rest of the week. You are, of course, an
expert in photoshop and all aspects of UX and UI design and should have a
professional-quality portfolio that extends from logos currently being seen by
hundreds of millions of people to animations and Cannes-festival shorts,
though this can be a relatively short stint in your career due to the low
amount of money that you were making. However, you should be confident in your
portfolio, and be very quick and competent in Photoshop so that you can
execute your vision as a visual 'spec' to code from later. Besides the 12-15
hours (loose, it does involve creative work) that Wednesday comprises, every
day between 7 PM and 11 PM you should be prepared to add to this creative
output, which adds another up to 18 hours. Your entertainment in these
evenings should also be creative and related to your output. Whether that
means watching documentories on art, or reading such books, the point is that
this is 'fun' for you and your lifestyle in the evenings is somehow related to
UI/UX and the types of questions that come with it.

Role 4: This is the most flexible role: it consists of counting money. The
accounting role should be able to performed quickly from 11 PM to midnight
every day when you don't have much money coming in (7 hours in a week), and
extend up to 2:30 AM or 3-3:15 AM every day - another 17.5 to 23 hours - when
you do. This extends into the hardest and most awake and alert "all-nighter"
period that a coder may think is best reserved for coding. Not so. To truly
grow on sales, you should devote your greatest attention with the most quiet
and fewest distractions to the bedrock of your business, which is counting
money. You should be very at ease with numbers, have a deep understanding of
accounting, to the point of nearly having a degree in the matter, and should
definitely have handled all aspects of a business's books in the past (short
of being an in-house accountant). This is where having run your own business,
any business, by yourself, including being a freelancer who had to invoice
themselves, will truly help you. However, when there aren't many accounts and
there isn't much money coming in nor accounts payable, nor a current round
underway or end of the month or quarter there may not be much to do here. Get
some rest.

Role 5: (And you thought I could only fit 4 roles in here!) In the morning
before 7 or 8, other than Wednesdays, when you're focusing on design from
first thing in the mroning, you can answer various quick emails, including
non-actionable customer emails, review any news or feeds - like hackernews,
have breakfast and generally start your day. Ideally, on normal days you sleep
from midnight to seven, and do various quick things like this from 7 to 8,
when you start your role of the day. You should be sociable and love getting a
bit of time every morning to do this stuff! It hardly feels like a role, just
something to break up the chore of boring stuff that you do all day every day.

Why not. Anyone who meets the criteria of the roles above should be able to
get a business off the ground as a sole founder and get a very far way along
as a sole employee.

As the business expands, you can get help with the accounting (to get more
sleep), then help with the programming - especially after all the initial
architecutre is set up and major features have been planned and begun to be
roled out - a very professional designer just as you yourself are, and finally
you will be left to meet with VC's all day to sell the company that you built
up all by yourself.

It is, after all, the logical conclusion to the present submission :) Note: I
have only proved the above possible, not tried it myself...

~~~
_feda_
such a schedule has burnout written all over it.

------
eswangren
Ummm... No, no thanks. We're not all UI designers. We just hired a UX guys
because I, as a systems engineer, am more valuable creating hardware
interfaces than user interfaces. You still need guys like me making things
work behind the scenes and that's where my time is best spent.

