Ask HN: Where to start with User Experience 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.

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

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.

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

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.

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