Ask HN: Where to start with User Experience Design?
When building a good web site or service that people are intended to use, where is the best place to start with the user interface and interaction design? Even if your site has a good idea or sophisticated technology behind it, if this part is done badly then the site fails to be useful for anyone. Alternately, superior usability trumps even the poorest of aesthetics as attested to by both stack overflow and News YC.
However, since good design doesn't come out of thin air, what resources would you direct me towards or what advice would you provide?
7 comments
Knowing your use-case actors is a primary requirement before anything else is done. You should have atleast 2 or 3 just having come up with the idea to build software (by that I mean you will have an implicit actor just by deciding someone needs a bit of software), but UI wise you need much more granular detail.
The implicit actor for your software is usually as simple as "a freelance developer needs to be able keep track of the time they devote to projects so they can effectively bill their clients while minimising time wasted on their own admin".
When you want to create use-case actors for the UI side you want to really think about people and not functions. The Joomla admin system is, in my opinion, an example of something that was written as a set of functional requirements without anyone attempting any user empathy.
A starting point here might be: "Tom is going into his second year as a freelance developer, having had a more successful first year than he had anticipated. Tom doesn't keep detailed time records and ends up partially guessing at the end based on emails but as he works with clients he likes he's been happily underestimating because his income is really good compared to his old job, and what is an hour or 2 anyway?
He has just taken on some work with a really well known agency who want work break-downs to 15 minute accuracy included with invoices, and while he doesn't really see what the point is, this is a big opportunity for him and wants it to go smoothly. He is also a little intimidated by his contacts at the agency and doesn't want to cause any conflict.
Tom is willing to run the time software for working with this agency, but at the moment doesn't really imagine the benefits to using it for his existing clients because it seems like more effort every day than it is just to do what he usually does at the end of the month."
From here you can extract lots of valuable information that will inform your UI cases. You know instantly for example that if you need to read a PDF to understand how to even start tracking project time this user will no doubt ditch the product because right now he is not really buying into the concept.
Case 1: The user must be able to record time information on a per-project basis to specified precisions, broken down by task.
Now look at Case 1 and ask yourself how you would go about building the task tracking UI for your actor. Would you build something like a tray app that he can quickly select the project, add a row into with a name, and then run a start/stop timer on that task? Would you add a way to show visual reminders that a task is still running every x minutes? Why? Or would you make it a system that you had to log into where you click into a project, then create a new task, then on the next page you can put in the time you spend on that task, save that and go back to the project panel, then swap projects and put in some new time against another task?
Both effectively do the same thing, but which one is Tom more likely to use for his current requirement, and more importantly for your business, which one might affect his opinion that it's more hassle than it's worth and would look to expand his use of your product to all his business (and this possibly be up-sold to)?
Writing clear and precise actors that have some empathy to them makes a huge difference to IA and UX as a complement to a good set of functional requirements.
(Note: I've cheated a little by basing my example to expand on as developers, as this makes it very easy to remove actors who don't understand technology that well).
And that is really a starting point, I've not touched on using real users to inform your decisions (though things like card sorting) and I would really suggest that if you use people to test wireframes or early designs you don't sit over their shoulder but screen-share with them instead, as people definitely tend to act differently when they are in a "test" environment with someone watching them.
When you want to create use-case actors for the UI side you want to really think about people and not functions. The Joomla admin system is, in my opinion, an example of something that was written as a set of functional requirements without anyone attempting any user empathy.
A starting point here might be: "Tom is going into his second year as a freelance developer, having had a more successful first year than he had anticipated. Tom doesn't keep detailed time records and ends up partially guessing at the end based on emails but as he works with clients he likes he's been happily underestimating because his income is really good compared to his old job, and what is an hour or 2 anyway?
He has just taken on some work with a really well known agency who want work break-downs to 15 minute accuracy included with invoices, and while he doesn't really see what the point is, this is a big opportunity for him and wants it to go smoothly. He is also a little intimidated by his contacts at the agency and doesn't want to cause any conflict.
Tom is willing to run the time software for working with this agency, but at the moment doesn't really imagine the benefits to using it for his existing clients because it seems like more effort every day than it is just to do what he usually does at the end of the month."
From here you can extract lots of valuable information that will inform your UI cases. You know instantly for example that if you need to read a PDF to understand how to even start tracking project time this user will no doubt ditch the product because right now he is not really buying into the concept.
Case 1: The user must be able to record time information on a per-project basis to specified precisions, broken down by task.
Now look at Case 1 and ask yourself how you would go about building the task tracking UI for your actor. Would you build something like a tray app that he can quickly select the project, add a row into with a name, and then run a start/stop timer on that task? Would you add a way to show visual reminders that a task is still running every x minutes? Why? Or would you make it a system that you had to log into where you click into a project, then create a new task, then on the next page you can put in the time you spend on that task, save that and go back to the project panel, then swap projects and put in some new time against another task?
Both effectively do the same thing, but which one is Tom more likely to use for his current requirement, and more importantly for your business, which one might affect his opinion that it's more hassle than it's worth and would look to expand his use of your product to all his business (and this possibly be up-sold to)?
Writing clear and precise actors that have some empathy to them makes a huge difference to IA and UX as a complement to a good set of functional requirements.
(Note: I've cheated a little by basing my example to expand on as developers, as this makes it very easy to remove actors who don't understand technology that well).
And that is really a starting point, I've not touched on using real users to inform your decisions (though things like card sorting) and I would really suggest that if you use people to test wireframes or early designs you don't sit over their shoulder but screen-share with them instead, as people definitely tend to act differently when they are in a "test" environment with someone watching them.
There are many books and all but if you want to just dive into it, here is the basic process you can build upon (this is how I design):
1) For every page of your site, list BIG 1,2,3. (Like what you want users to do, and two alternates).
2) Now design around that. Make it easier and obvious to follow your 1,2,3 (If there are more than 3 steps - you might wanna break them into more pages).
3) Remove noise and barriers that come in way of BIG 123
4) Test, test, test & Optimize
It's a very short description of how to go about it. But you gotta do it to know what I am talking about.
The aim is to design an experience around user.
Once you've practiced this at least with one project,you can dive into awesome articles at:
http://www.uxbooth.com/ http://www.uxmagazine.com/ http://www.uxmatters.com/
Just read what interests you, but before - practice the above, so you can relate to what they are talking about.
1) For every page of your site, list BIG 1,2,3. (Like what you want users to do, and two alternates).
2) Now design around that. Make it easier and obvious to follow your 1,2,3 (If there are more than 3 steps - you might wanna break them into more pages).
3) Remove noise and barriers that come in way of BIG 123
4) Test, test, test & Optimize
It's a very short description of how to go about it. But you gotta do it to know what I am talking about.
The aim is to design an experience around user.
Once you've practiced this at least with one project,you can dive into awesome articles at:
http://www.uxbooth.com/ http://www.uxmagazine.com/ http://www.uxmatters.com/
Just read what interests you, but before - practice the above, so you can relate to what they are talking about.
Thank you for your advice and the links.
Sure man! Always happy to help in design, UI & UX :)
I agree with weego that the place to start with user experience designs is with THE USER. Describe these (assumed) primary and secondary players that support whatever business and marketing efforts you've got.
Simple persona style might be:
-- Jim is 32, an accountant, online 4-5 hours a day, has an iPhone, 2 toddlers, and no time for anything except his fantasy football league and the occasional game of Angry Birds while on the metro each morning. --
By getting my team or clients onboard with Jim right out of the gates, I've found that I can say "Seriously, 'Jim' doesn't care about button colors or sharing this on Facebook," when projects typically might otherwise get distracted, and the development cycle then stays more uniformly focused on the user (our ultimate goal, usability wise).
Then, I complement this user development with MEANING creation. What does "Jim" really care about? What core aspect of our app makes his life easier, means more to him, or is /the/ most entertaining way to engage his attention?
From there, I'd build (ugly) only that feature/interaction with great content that provides necessary cues, then go find a few Jims. Test, re-test, evolve, and FINALLY layer in the pretty (and additional features essential to bolstering usability... not just for the purpose of adding stuff).
Rinse and repeat for all target audiences. Well, repeat anyway. :)
Simple persona style might be:
-- Jim is 32, an accountant, online 4-5 hours a day, has an iPhone, 2 toddlers, and no time for anything except his fantasy football league and the occasional game of Angry Birds while on the metro each morning. --
By getting my team or clients onboard with Jim right out of the gates, I've found that I can say "Seriously, 'Jim' doesn't care about button colors or sharing this on Facebook," when projects typically might otherwise get distracted, and the development cycle then stays more uniformly focused on the user (our ultimate goal, usability wise).
Then, I complement this user development with MEANING creation. What does "Jim" really care about? What core aspect of our app makes his life easier, means more to him, or is /the/ most entertaining way to engage his attention?
From there, I'd build (ugly) only that feature/interaction with great content that provides necessary cues, then go find a few Jims. Test, re-test, evolve, and FINALLY layer in the pretty (and additional features essential to bolstering usability... not just for the purpose of adding stuff).
Rinse and repeat for all target audiences. Well, repeat anyway. :)
Is it just me, or there a new one of these threads once or twice a day now?
From a couple of emails I recently sent out:
"I'd suggest starting out with 'The Non-Designer's Design Book,' which explains the basics of putting elements on a page or screen together in a tasteful way; 'The Humane Interface,' which explains testing and measuring for efficiency and why dialog boxes are often bad and so on and so forth; and 'Designing for Interaction,' which is often cited as a good overview of the practice of interaction design, and I just flipped through it and it seems to be, although I haven't read it."
"If no-one [on your team] is a designer and you don't want to hire one, help everyone become a designer. Buy these books, a copy each for everyone, and make everyone read them and discuss them with each other, cover to cover, no exceptions, everyone doing all the exercises in them."
"After everyone has dog-eared copies of those three books, have everyone pick a different book from this list and buy it and read it and present it to everyone else, and then repeat that until all the books have been gone through: http://www.facebook.com/topic.php?uid=114778998560307&to...
From a couple of emails I recently sent out:
"I'd suggest starting out with 'The Non-Designer's Design Book,' which explains the basics of putting elements on a page or screen together in a tasteful way; 'The Humane Interface,' which explains testing and measuring for efficiency and why dialog boxes are often bad and so on and so forth; and 'Designing for Interaction,' which is often cited as a good overview of the practice of interaction design, and I just flipped through it and it seems to be, although I haven't read it."
"If no-one [on your team] is a designer and you don't want to hire one, help everyone become a designer. Buy these books, a copy each for everyone, and make everyone read them and discuss them with each other, cover to cover, no exceptions, everyone doing all the exercises in them."
"After everyone has dog-eared copies of those three books, have everyone pick a different book from this list and buy it and read it and present it to everyone else, and then repeat that until all the books have been gone through: http://www.facebook.com/topic.php?uid=114778998560307&to...
Instead of reading books, why not organize weekly Friday user afternoons: invite three users to use your product. Or a competing product if yours is not ready. Every freaking Friday. Invite the team, too, with pizza and beers.
Better than any book.
Better than any book.
There are actually a couple of books that can probably help with this kind of
informal user experience testing. Both are by Steve Krug. The first is "Don't
Make Me Think" which focuses on design for usability, and includes a chapter
titled "Usability Testing on 10 Cents a Day". The second is "Rocket Surgery
Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability
Problems" (already mentioned by petervandijck). This is a newer book (2009)
that goes much more deeply into usability testing for people whose primary
responsibility is design and development rather than user experience. It's a
great book in spite of the cutesy name.
I think you need an understanding of the basics before you can start to evaluate why users are doing what they do and how to fix problems they have.
The rest of the emails I've sent out recently do recommend that next, though. I just think you need the fundamentals, first!
The rest of the emails I've sent out recently do recommend that next, though. I just think you need the fundamentals, first!
I suggest keeping a clip file. Anytime you see something you like, take a screenshot and save it (locally, create a gallery on Picasa, etc.).
Then figure out exactly what it is you like about the sample. Break it down, see the individual elements and think about how you'd implement them in your own design.
That way you can learn the techniques (how to fish) and avoid wholesale copying.
Then figure out exactly what it is you like about the sample. Break it down, see the individual elements and think about how you'd implement them in your own design.
That way you can learn the techniques (how to fish) and avoid wholesale copying.
1. Be clear about the problem you're solving.
2. Watch (in person) real people using your website trying to solve this problem. Many times. Fix the most glaring problems.
This is the best book to learn usability testing, and the only one I would recommend: http://www.amazon.com/Rocket-Surgery-Made-Easy--Yourself/dp/...
2. Watch (in person) real people using your website trying to solve this problem. Many times. Fix the most glaring problems.
This is the best book to learn usability testing, and the only one I would recommend: http://www.amazon.com/Rocket-Surgery-Made-Easy--Yourself/dp/...
[deleted]