Vitorio resides at vi.to
He’s a UX designer.
He organizes UX workshops and meetings in Austin, USA.
Inspired by his initiatives, I had sent him a mail seeking guidance on how to conduct a workshop. When my initiative didn’t turn out as expected, I sent him another mail seeking guidance in the practice of IxD. His reply was incredibly thoughtful, detailed and prompt – it left me feeling extremely surprised and grateful.
I believe that his advice can be of benefit to many more Interaction or UX designers who’ve just gotten into this field and are trying to figure out how exactly to practice UX and deliver solid value as a UX designer.
But now that I’m practicing IxD, I find it to be very vague and unstructured. Can you suggest some specific exercises that will help me improve my chops?
For eg., as a computer engineering student, it was very easy for me to gauge if I was making progress with my coding chops. I feel that there is simply no similar metric for IxD.
That’s not true at all, it just takes a little more work.
If you’re coming from engineering, it may make more sense to focus on information architecture and usability first, rather than layout and visual design. Jef Raskin’s book The Humane Interface talks about measures of usability, like Fitts’s Law, Hick’s Law and GOMS, and these are systems which you can actually use to measure physical interactions, and thereby determine if one interface is more efficient than another. Software like CogTool lets you calculate some of those automatically.
Information architecture isn’t just about how data is organized across an entire piece of software or web site, it’s also about how it’s organized on the screen. Imagine the structure of a web page: you have a <title>, and then a first level header <h1>, and then subheaders <h2>, and maybe an <h3> on occasion. Some text <em>phasized and some text is <strong>ly emphasized. If you’re focusing on usability, then a user has a task to accomplish, and your information architecture needs to support that task. The most important piece of information a user needs to know to accomplish that task is your <h1>, the next set are your <h2>s, and so on and so forth.
By taking this analytical approach, you can produce measurably better software even if your layout and visual design is sparse, and it helps you prioritize things when you start getting into layout and visual design.
You still have to validate with actual users, of course: they may not understand the priorities, even if the information is correct in total, for example. Or you might be wrong about how they do their task. Testing your work can be as simple as drawing out each possible screen and sitting down with a friend or stranger and having them conceptualize going through the motions of the task and seeing if the understand what you’ve drawn. But, even if you don’t test (you should always test), you will at least have a solid theoretical foundation.
For layout and visual design, some of the best references are print design references. Robin Williams’ The Non-Designer’s Design Book focuses on a handful of key principles which you should master, and includes exercises you can apply to software or web design, by taking your software, condensing it down to its information architecture, and re-designing it using each principle in turn.
From a process perspective, I’m told Dan Saffer’s Designing for Interaction is also good for beginners, but I haven’t read it. Bill Buxton’s Sketching the User Experience might be interesting, because it now has a companion workbook available, with exercises to practice with. I haven’t tried this either, though.
Finally, you want to think things through, end-to-end. Design doesn’t come from pure, genius inspiration. It comes from critical thinking after becoming well-informed. You’ll see lots of designers playing with Photoshop redesigning home pages and single application screens. Don’t do that. Instead, pick a site or application, something you use, something your friends use, something your parents use. Use it. Watch them use it. Figure out a primary task that they do there and study it, see where people get confused or where it’s not as easy or automatic as it could be. Find someone who has never used it before and watch them try and figure it out. Then take that entire process, end-to-end, it might be dozens of pages or screens, and redesign the entire thing. You can draw the original one in CogTool and then draw your redesign to compare them, or you can do testing with users and paper prototypes, or you can mock it up in HTML or your programming language of choice. (Don’t forget that all the ancillary information on the screen that isn’t related to the task, might be there for a reason. Figure out what it is, or put it away and explain where and why.)
And then you do it again. And then again. And then again. And you document your thought process and your changes and the test results, and that becomes your portfolio.
And then you try it on some other site or piece of software.
A good designer is a journalist, and a scientist, and an artist, and a salesman, so you have to practice all of these things together, all of the time.
This is the best advice I can offer.