By law of nature, I make notes during such a day. I didn’t, however, make a full summary; so I can only give an impression with a couple of loose remarks and quotes and ideas.
Anyway, the day was bits of theory interspersed with group exercises, culminating in a design that we tested with paper prototypes. To start off I’ve got a video of those tests. (If you don’t understand Dutch: scroll through to the 1 minute mark. That way you at least get a nice impression on how a paper prototype can work.)
A core idea is mental modeling. What is the mental model of the user? What mental model should he have in order to use your app or website? What mental model of reality does the user already have? Which terms or concepts should you use in your app or site?
Interviews are important to get this clear. And if you interview or if you observe someone: listen. Listen a lot. At least initially. You are the student, the user is the teacher. Take time to gain trust. And when you do ask questions, try to get to the bottom. The user might say something, but after asking “why” five times, digging ever deeper, you might get a different answer than originally. Alternatively, use the why/where/what/when/who kind of questions.
Why are mental models important? Well, you make them anyway when interacting. Enter a building and you see the door knob: you automatically make a mental model of that door knob and the way you expect it to behave when you interact with it. Should I push or pull or whatever?
So when your site or application has a good and consistent mental model behind it, it will provide you and your user with something to hold on to: it helps you explain what happens and it helps you understand what happened and what is about to happen when you interact with it.
A very good requirement you can force upon yourself when you make a mental model: you should be able to explain it to your grandma within two minutes.
Tell stories. Human beings like and relate to stories. So write down textual usage scenarios (or visual: simple comic strip). Use specific thought-up “personas” like “Harry from accounting who positively hates computers”. And try to get together a representative number of usage scenarios.
Those scenarios, when written down, help get discussion underway. If you only tell what you’re going to do, it is easy to nod your head and to agree. If you see something written down that’s obviously wrong or obviously missing key elements… Discussion! This way you gain clarity quickly. And… you gain clarity before spending four weeks programming something!
After gaining clarity in this way, the next step is classification. Basically: find the right words. Nouns and verbs. The terminology you use for your application. Spend time getting this right.
Btw, make a difference between information structure and application structure. The information structure means the content. “Article”, “blog post”, “map layer”. So: the core data structure. The application structure, on the other hand, is much more about about the form/layout.
(Note: he mentioned the elements of user experience by Garrett (link to PDF with the main graph). The way I understand it now as I can actually read the graph is that the information structure/application structure difference is more of a “duality” that needs to be resolved in the resulting visual design.)
Conceptual design is the next phase: design the main structure of your website. Items like:
Session management and login behaviour.
How will we handle search/filter/browsing?
So basically: converting the output of the classification/terminology phase to a navigation. Tip: make wireframes or mock-ups of the various screens and draw the navigation (the flow) between those wireframes. He called it a wireflow.
Apparently designing interfaces by Jenifer Tidwell is “the bible” for stuff like this.
When designing, use four Gestalt principles: proximity, similarity, continuity and closure. (The page linked has five items, btw).
And keep in mind that too many choices mean that a task takes too much time (Hick’s law), so don’t put in too many choices.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):