You don't need a UX specialist(blog.123ship.it)
blog.123ship.it
You don't need a UX specialist
http://blog.123ship.it/2013/03/you-dont-need-ux-specialist.html
7 comments
Agreed. Original article is a dismissal of the amount of research and consideration that goes into UX.
I'm sorry, but as someone who does UX full-time, I couldn't disagree more.
I used to be a developer who felt the same way. All of this stuff is just common sense. Then, I decided to do a career transition into full-time UX and spent a year studying intensely.
Now, I look back on my old self and laugh. Practically everything was wrong, and some things were horrifically wrong. There's just too much to think about and too many fundamental concepts that you must be aware of to do good UX (Gestalt principles, color theory, design patterns, etc.)
The way I feel about this post is about the same as developers out there feel when your uncle says "How hard can web development be? My nephew made me a website in Wordpress in a couple of weeks"
I used to be a developer who felt the same way. All of this stuff is just common sense. Then, I decided to do a career transition into full-time UX and spent a year studying intensely.
Now, I look back on my old self and laugh. Practically everything was wrong, and some things were horrifically wrong. There's just too much to think about and too many fundamental concepts that you must be aware of to do good UX (Gestalt principles, color theory, design patterns, etc.)
The way I feel about this post is about the same as developers out there feel when your uncle says "How hard can web development be? My nephew made me a website in Wordpress in a couple of weeks"
Totally agree here. There's a lot of domain knowledge that goes into making things easy to use/learn. The entire goal of UX is to make it seem simple -- but PRODUCING something simple isn't!
Since you transitioned into full-time UX starting as a developer originally, I am curious as to what resources you utilized to improve your knowledge of good UX principles.
I've been meaning to write a blog post on it, but you know how it goes. Never enough time.
Basically, it comes down to study + experience. But study is absolutely a necessary prerequisite; otherwise you have no criteria to decide what went wrong when something fails.
I did a post here about some books that I found useful
http://www.jeremytunnell.com/posts/books-on-user-experience-...
I basically spent a year working part-time and studying part-time. I read every UX book, article, and website that I could find, and then I got experience by offering to do a heuristic analysis for startups on the Washington DC hacker news list for $20 per hour.
This kind of thing:
http://www.jeremytunnell.com/posts/watchparty-tv-a-usability...
Basically, it comes down to study + experience. But study is absolutely a necessary prerequisite; otherwise you have no criteria to decide what went wrong when something fails.
I did a post here about some books that I found useful
http://www.jeremytunnell.com/posts/books-on-user-experience-...
I basically spent a year working part-time and studying part-time. I read every UX book, article, and website that I could find, and then I got experience by offering to do a heuristic analysis for startups on the Washington DC hacker news list for $20 per hour.
This kind of thing:
http://www.jeremytunnell.com/posts/watchparty-tv-a-usability...
[deleted]
I kinda agree with the headline, but only because I think the followup is "Instead, you should become a UX expert".
I think many developers do themselves a disservice by not working to get good at this stuff. It's not magic, but it takes consistent, conscious practice like any other skill. What's more, every time you sit down to code is another opportunity to practice, because every program has a user, and every user has needs, expectations, and frustrations.
I think many developers do themselves a disservice by not working to get good at this stuff. It's not magic, but it takes consistent, conscious practice like any other skill. What's more, every time you sit down to code is another opportunity to practice, because every program has a user, and every user has needs, expectations, and frustrations.
Lets (for a moment) agree that we can achieve 99% of UX via common sense.
The question I would ask is: Would you make the same argument for Typography? (I know, seems completely unrelated)
Typography, we can say, is just making text readable, organized, and appealing. We can all read some info about kerning, leading, and spacing, and their common ratios. Then, pick up a 'modern' typeface and that would then bring us to 99% of making a new webapp/site beautiful in terms of type?
The question I would ask is: Would you make the same argument for Typography? (I know, seems completely unrelated)
Typography, we can say, is just making text readable, organized, and appealing. We can all read some info about kerning, leading, and spacing, and their common ratios. Then, pick up a 'modern' typeface and that would then bring us to 99% of making a new webapp/site beautiful in terms of type?
This is insulting to UX designers. It's the equivalent of saying to a dev "development is easy, just keep it simple and use common sense". Absurd.
Then you also don't need designers - you can just use common sense of taste instead! Easy-peasy!
Graphic designers are not UX designers. If that's where the author's been getting their ideas about UX, it's no wonder they don't see the value.
The ability to understand your users, then prioritize and design an experience that will serve their needs while balancing business requirements and the need for speed to get to market is far more than "common sense."
A hierarchy of things _you_ want is not going to get you to a good experience.
If you need to build an MVP quickly, and don't want your UX to suck (and you can't get a dedicated UX person on your team), I would provide this alternate set of steps:
1. Know who you're building it for. Remember the mantra "you are not your users." Even if it just means reading some published data or articles about your users, or having a chat with a few people, anything is better than nothing. Start from their perspective, not your own.
2. Tell yourself a story. The best way to design a product is to design the story of your product. Instead of starting with features and hierarchies, start by going up to the whiteboard and drawing a few user flows. Name your user, so you're thinking of them like a real person. (DON'T make complicated profiles or use silly names. It's enough to just think "would Sally want to do this?")
3. Use your story to design your features. If there was something in your flow that was vital, then use that feature. If you found yourself saying "yes, but she could always do -n- instead for now," it's non-essential, and you can leave it out.
4. Grok usability. If you don't have anyone on your team who knows what Fitt's Law is, or why the 10 Heuristics matter, find someone who does. This is where "common sense" leads most people, graphic designers especially, into pitfalls. There are a lot of UX professionals who are happy to give your product a once-over and point out the hidden traps you might have missed. You probably have a friend who does this for a living, and would love to help you.
5. Build early, iterate often. This is where the author gets it right. There's no substitute for the real world. Instead of long periods of usability testing on prototypes, if you can handle an imperfect product going live, you're better off watching how real users deal with it, and iterating quickly when problems arise. Use tools like Crazyegg, Clicktale, or Mouseflow to see what's really happening and react. Don't wait for users to tell you what's wrong, because they often can't (or won't bother to) articulate the problem for you.