Don't look for a UX guy, be a UX guy(blog.factlink.com) |
Don't look for a UX guy, be a UX guy(blog.factlink.com) |
"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.
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.
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.
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.
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
Does our position really require years to master? Is a java or ruby programmer with 10 years experience that much better than a java or ruby programmer with 3 years experience?
What about design? Is building a website, interactive component or application so complex that only those with decades of experience can really 'get it'? Is someone who has twenty years of UX experience, dating back to the days of VB and Access applications, that much better than someone with five years?
I believe combining technical with creative is something that must be taken as a given with our industry.
I don't touch UI's in my day job. You make it sound as if all programmers code UI's and perform other relatively mundane tasks. That may be what you're used to, and yes, it is relatively easy work, but there are a bunch of people like me out there who design infrastructure at a low level so that you can more easily build software at a high level.
However, all I'm saying is you can't realistically become an EXPERT in both.
I run a business... over the last few years I've been doing a bit of sales, accounting, programming, project management, IA/UX design, QA, long-term strategy planning, etc. Has it helped me that I know how to do each one a little? Yes, of course. Am I expecting to become an expert in all of them? Absolutely not
I think in the educational system, as children and young adults we are taught that we must excel at as much as we possibly can. When, the reality is, doing really well in one area means your skills in another will weaken -- especially when you are trying to do them at the same time.
Ever met an accountant novel writer who base jumps on the weekends? I haven't.
Likewise, skills are generally not mutually exclusive: the more mental models you have, the smarter you think. For example, there are some areas of UX which are relevant to API design. In fact, there are similarities between almost everything in life.
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.
Why does that show that "they don't know what they are doing"?
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
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 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.
everyone should be aligned, everyone should be focused on the audience they are building for and the needs of those users. that is what differentiates a stripe from a google checkout and, to be cliche, an iphone from a treo.
even the concept of having a "ux guy" means there are others in the org who are "not ux guys"
there is nobody at most of the companies who model "good ux" responsible for that "good ux"
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.
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.
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.
Sounds a lot like anything you can iteratively improve. Could also be applied to marketing, cold-call-sales, making a great coffee, ...
>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...
(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.
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
No, let's trivialize it. What exactly do you do on a daily basis? Give me an example of a task that you worked on that took a lifetime to master. Something that you could only truly appreciate after years of focused experience.
One was implenting an image quality algorithm for a medical imaging system. I did not do this on my own, but I will wager that it was far more complex and involved than any UI code you last wrote. I had to understand the science behind the algorithm, implement it, and then make it fast (it is run on huge images).
My next project was optimizing a heap memory manager for the device which captures these images. Not PhD level physics here, but not trivial and not something I would expect a UX guy to do.
So yeah, I take a bit of offense when you lump all programmers into the same bucket. Not all programming is engineering IMO, and to compare writing a UI to writing a thread scheduler, a memory manager, a new programming language, etc. is just ridiculous.
I'm not saying that UI work is dumb simple. It is incredibly hard to get right, but that kind of complexity is not technical. It takes a certain kind of aptitude and knowledge to do work that is closer to the metal and closer to concepts taught in CS. Creating a UI is not CS, it is wiring up bits of code that other people wrote in a such a way to be useful to a non-programmer.
So yes, a UX guy could probably be writing his or her own UI's in about 6 months to a year. I would not hire this person into the group I work on because they will be overwhelmed by technical complexity that they simply won't be able to handle.
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.
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.
My life experience has taught me this couldn't be more wrong.
To be a great engineer you need to be smart.
To be a great ux guy you need to be smart.
To be a great product guy you need to be smart.
As someone doing all these 3 and more. I live by the saying that a smart person can be anything he wants (intellectually). And the only limits I've seen in a smart person are only what he tries to be good at. If you're smart, you'll be good at it. That whole different types of intelligence hypothesis is pseudoscience.
We both seem to agree that your run-of-the-mill Java programmer working for the autozone website is not a complicated position.
We both seem to agree that your run-of-the-mill UI/UX person working for the same autozone website is also not complicated.
I bet you would agree that designing the interface for the first consumer focused touchscreen-only device is something that is very complicated.
Just like I agree that working something that deals with ct scans, ultrasounds, 3d printing, 3d rendering, product delivery and a host of other problems are very complicated.
The real point is that you should know your industry, and yes all of our industries are a little different. If you are working on the Accuvix V20 Medison ultrasound system I personally believe you should know how to turn the thing on, point it, run the scanner, understand the readouts (to a certain degree) as well as understand the inner-workings of the image acquisition and processing. I believe this is just what helps people make more informed decisions. This doesn't mean you suddenly have to be a UI/UX person, it simply pushes you to know the complete lifecycle and have some competency in the product you are working on.
Should you be a UI/UX person? No. Should you know why the UI/UX decisions are being made? Absolutely. Knowing that will help you write a better system, it will also help you bring to light more possibilities.
I mean, would you call Jonathan Ive a "UI guy"?