Don't look for a UX guy, be a UX guy (opens in new tab)

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.

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

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.

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

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.

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

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.

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.

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

"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, ...

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.

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

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

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.