

Ask HN: Where to start with User Experience Design? - Kaizyn

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?
======
weego
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.

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

~~~
Kaizyn
Thank you for your advice and the links.

~~~
kingsidharth
Sure man! Always happy to help in design, UI & UX :)

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

------
vitovito
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...](http://www.facebook.com/topic.php?uid=114778998560307&topic=130)

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

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

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

------
petervandijck
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/...](http://www.amazon.com/Rocket-Surgery-Made-Easy--
Yourself/dp/0321657292/)

