DonnaM » Interaction design

Interaction design

Conference season

Thursday, January 29th, 2009

For me, the next few months are full of conferences and workshops. My calendar is so packed I don’t know where the work will fit. You can catch me at:

I hope I see you at one or more of these.

And remember, I can teach any of these workshops in-house to your team (see my list of IA, interaction design, usability & content workshops).

Article: Designing and selecting components for user interfaces

Wednesday, December 3rd, 2008

The User Interface Resource Centre have published an article I wrote for them called What, Where, How: Designing and selecting components for user interfaces.

The article is about how to make sure your components will be usable and easy to learn. It covers some fundamental cognitive principles and their implications for component selection.

Website user experience & CSS workshop

Tuesday, February 19th, 2008

I’m very excited to announce that I’m teaching a new workshop with Russ Weakley. It’s called “Website user experience & CSS workshop: Designing for usability, building for the future“. It will be run in Canberra, Melbourne, Sydney and Brisbane, in late March and April.
I’m teaching the day on user experience, and Russ is teaching on CSS, which is lucky for you as I’m pretty good at ux and Russ is awesomely good at teaching CSS.

I’m really looking forward to it – I’ve wanted to go to one of Russ’ tutorials for a couple of years. And I love teaching user experience design for the web – I’ve spent a lot of time doing it, and a lot of time thinking about what I’ve learned and how to best share it.

I hope to see you, or your colleagues, there. Please pass details on to anyone you think may benefit.

Workshop description

A hands-on workshop with user experience expert, Donna Maurer, and CSS
expert, Russ Weakley.

Over two full days you will build detailed websites layouts from the ground up – starting with page layout, navigation and form design; and ending with clean markup and elegant styling using XHTML/CSS.

Day 1: Planning and designing the user experience – Donna Maurer

On day one you will plan and design a website – focusing on the user experience: designing the navigation, page layout and forms.

You will:

  • learn techniques to understand your users, and prepare user scenarios
  • understand your content with content analysis methods
  • create an effective and usable site structure (information architecture)
  • design a range of navigation methods
  • create page layouts for content, home, index and special pages
  • design simple forms

For each step, Donna will outline the fundamentals and show examples from small and large website projects. But most of the time will be hands-on -you work on your own project, ask questions and discuss with the group.

Day 2: Building beautiful sites using CSS – Russ Weakley

On day two you will build your website from the ground up – starting with structural markup, adding accessible markup and then styling your layout using CSS.

You will learn:

  • how to create well structured, accessible markup
  • the basics of CSS including rule sets, selectors, shorthand rules, inheritance and the cascade.
  • how to structure efficient CSS files
  • how to create a full CSS layout from a flat graphic mockup
  • how to deal with browser issues including specific browsers such as IE5,IE6 and IE7.
  • how to create a resolution dependent layout
  • how to create CSS for printing and hand held devices


Canberra – Monday 31 March and Tuesday 1 April

Melbourne – Thursday 3 April and Friday 4 April

Sydney – Monday 28 April and Tuesday 29 April

Brisbane – Thursday 1 May and Friday 2 May


More information and registration here:

Why be an interaction designer

Tuesday, August 29th, 2006

From Dan Saffer’s latest article:

Why Be an Interaction Designer?

So you can change the world, of course. Sure, it might look like we’re tinkering with buttons and drop-down menus and jog dials, but really what we’re doing is changing our world—one little bit at a time—making it more humane. We help people do their everyday tasks whether they are playing a game, saving a life, or moving money from one account to another. We’re injecting the world with our values: what we think is useful, usable, pleasurable, and good. And that’s not a bad job to have.

That’s why I’m an interaction designer.

Things you should know before working with me

Tuesday, June 20th, 2006

I have often thought about how I work with people, and how people work with me. My work is a bit odd, and I’m a bit odd and people don’t always know what to expect.

So here’s a guide to what you need to know before working with me (in the context of me doing interface design and information architecture work for a project):

  • I may spend a long time seeming to do very little. Don’t panic – I’m thinking. Exactly what you pay me to do.
  • I spend a lot of time with earphones in. That means I’m trying to think and concentrate amongst the chatter of an office, not that I’m anti-social.
  • If you give me a gantt chart all arranged in linear order, I’ll nod and get to the end on time and budget, but not by the path you set.
  • I spend a long time gathering information and thinking, and little time producing towards the end. Once I have nailed an idea, all else is straightforward and fast. So if you think I’m going to miss a deadline because I haven’t produced much, stop worrying.
  • Outputs need inputs – I have experience, but I can’t design a good system out of nothing. I need to base it on something. Don’t stick me in a corner and not let me research and talk to people.
  • Teams are good – I have lots of experience at what I do. But so do you and the team. Let’s work together to create something great. Don’t make me work by myself and expect me to produce miracles.
  • I’ll occasionally rant and get passionate. That means I care.
  • Give me challenging work, give me time to work through it and we’ll get there. Don’t expect me to to hard work in the same time I do easy work. That’s just dumb.
  • If there isn’t enough work, I’d genuinely prefer to be at home. I’m not hanging around to chase dollars.
  • I hate banging my head against a political brick wall. I’d prefer to be anywhere else – that’s just a waste of time.

So, that’s me. Let’s go!

[Note: I wrote this over many months and will continue to tweak it, so it is not aimed at any previous client.]

Using qualitative & quantitative data

Saturday, May 13th, 2006

I was thinking tonight about user research in projects, and how I use what I collect.

In the main, I try to get user research from as many sources as possible (interviews, surveys, card sorts, usage stats, emails etc). But I only need a small amount from each source. In doing qualitative analysis, patterns repeat themselves quickly, which means I really only need a small number of responses to inform my design decisions.

But inevitably I collect much more than I need. And the reason I do so is not because I need it to learn, but to defend design decisions. With a bigger bulk of data, I can produce some statistics, as rubbery as I know they are (I was once a statistician), to provide credibility and to support decisions in an easy way.

Based on research for my card sorting book, that’s what many of you are doing as well – trying to get a bulk of responses to convince others that you have made the right decisions. Much more so than just informing yourselves, combining it with other research and making the creative leap.

I don’t know there is an easy way out of this situation. I very occasionally flash my bio if I know this will influence people, but I always feel grubby doing it. I feel that I shouldn’t need to support my decisions with rubbery statistics, but managers don’t have time to understand the detail – statistics are the easy way out that they will believe and let me go about creating good work.

Usability for RIAs

Tuesday, February 21st, 2006

My first digital web article has just been released – Usability for rich internet applications.

It is a look at some of the key challenges for designing rich internet apps, and making sure they are usable.

I talked about this at a recent web standards group meeting, and you can look at my slides for that presentation.

I’ll also be thinking about this more over time and expect to be talking about it further at Webstock in May.

As predicted – Jakob says Ajax sucks

Tuesday, December 6th, 2005

Here’s when I wish the podcast of my web standards group pres didn’t break. But those there will remember my prediction. It went something like this:

“Shortly, I’m sure Jakob will say that 99% of all Ajax sucks; and we’ll be doomed to an interaction-poor internet and a huge round of stupid arguments for a couple of years”.

So here it is: Why Ajax Sucks (Most of the Time)

Heh. I nearly fell for it (this is a spoof article, I hope you read to here)!

Getting involvement with prototype interfaces

Friday, November 18th, 2005

There is a funny piece of rhetoric from the user-centred design world – it says that when showing prototype interfaces for the first time they should be hand-drawn and rough, not computer-drawn and tidy. The theory says that people are more likely to tell you what they think when things are still rough.

This has always caused me a problem as my handwriting is awful! Although I love hand-drawn sketches for their speed and flexibility, I am always surprised when people actually understand what I have done, as even I find them hard to read.

So lately I have been using a combination of hand-drawn and computer drawn interface sketches. My hand-drawn sketches are very high level and communicate the shape of the application (as the detail is unreadable anyway). As long as I’m on the right track with that, I go to computer pretty quickly so people can read and consider the detail.

But to get around the issue of getting feedback on tidy drawings (and I’m still not convinced it is a problem), I do a couple of things:

  • Print parts of the interface out on different coloured paper and cut them out like a jigsaw
  • Highlight parts of the interface with coloured markers
  • When demonstrating, have spare markers on the table, and draw first
  • Take along spare copies of the interface and scissors, and cut out

The second-last point is the most important one. Grab a marker and scribble on your own work. It’s fine to be messy. This helps to break the social taboo of drawing on something that is tidy. If people still look hesitant, hand them a marker and ask them to draw. This more strongly communicates that it is OK to get involved. Cut out spare parts from the copies, and re-assemble interfaces, and hand the scissors around for others to play as well.

I believe that we have an ingrained taboo about touching someone else’s work, and particularly about writing on something tidy (maybe we’re afraid of our mothers jumping out and yelling at us for writing on a book).

It only takes a little effort in a design exercise to communicate that this is OK, and even encouraged. Go for it!

It’s not about size, it’s about context – radio buttons or drop-downs

Friday, October 21st, 2005

I’ve spent an extraordinary amount of time this week thinking about radio buttons. And I’d like to tell you what I’ve concluded.

I’m designing a complex web form with lots of fields to fill in, most of which are text fields or mutually exclusive option lists. My decision, for a public-facing website, is between drop-down lists and radio buttons.

The popular guideline, and I have found this written in many many places, is that it depends on the size of the list. If the list is long use a drop-down, if it is short use radio buttons.

But in real life, when you actually think about what you are trying to achieve, it is rarely as simple as black and white guidelines.

I’ve been thinking about the decision more deeply and have concluded that it has nothing to do with length of a list, and everything to do with the user context.

For this design decision, the following user contexts are the most relevant:

  • Familiarity with the domain – when users are unfamiliar with the domain (or the fields to fill in) they need additional assistance to understand what they are being asked to do. Radio buttons assist by showing all options on the screen, communicating the domain/field at a glance. However, when users are familiar with the domain it is OK to hide the options in a drop-down list – users can determine what they need to supply from the label (think of a list of States as an example).
  • Task efficiency – On a long form, or something that will be used frequently, users want to complete it quickly. A drop-down list requires the user to read the label, interpret it, click on the box, locate the correct item and click on it again. A radio button list allows the user to read the label and list at one glance, locate the correct item and click on it. Radio buttons are far easier and faster to interpret and select.
  • Screen real estate – In the GUI days, screen real estate was a real issue. Drop-down lists were preferred to radio buttons simply because they took up less room. Most of us are now designing for browsers and this isn’t as important. Not only do we have no control over the window anyway, but there’s a magic gadget called a scroll bar.
  • Size of list – In the GUI days, this was the determining attribute – long lists used drop-downs, short lists used radio buttons. In reality, there is little cognitive difference. The size of the list doesn’t change, so the time to identify the correct item and select it is similar between the two situations. However, as mentioned above, a radio button list may be faster as it doesn’t need to be opened and can be easier to take in at a glance.
  • Frequency of use – For infrequent users, radio buttons are clearly better, due to the concepts outlined above. For frequent users, two things are relevant. Spatial familiarity is important – we become familiar with placement of items on a screen and can fill them in quickly by remembering the spatial placement of items in radio button lists. However, frequent users often use a keyboard; in which case, drop-down lists are better as they allow people to type the first letter of the list and use the keyboard to get to the target item.
  • Interface balance – It is still important that the screen has overall balance and directs the eye appropriately to the flow of the form. When the factors above are equal, go with whatever balances the interface.

It should be clear from the above description that my preference is often for a radio button list, particularly for complex interfaces for infrequent visitors with imperfect domain knowledge.

I’m not usually one to issue declarations or write guidelines, so please don’t take this as a list of rules. Instead, please think about your situation, your users and your domain, and make a decision based on that. Don’t listen to stupid, glib rules that were written 15 years ago ;)

Do your IT projects fail?

Wednesday, May 18th, 2005

Alex has written a very clear guide to the way IT projects should be run to create more usable products and reduce failures and blowouts. If you are stuck in a cycle of IT project failures, go read it – he’s a smart fellow who knows what he’s talking about and doesn’t hesitate to do what needs to be done:

Usable methods : a convoluted practitioners haphazard narrative for usability good-enough practice

When IA meets interaction

Monday, March 14th, 2005

In the recent past, I’ve been known to say that designing for information and designing for interaction are quite different, and require a distinctly different set of techniques. I have also often commented that many people peddling user-centred design have missed this point and have tried to apply a set of techniques that are irrelevant to information-rich spaces (yes, sometimes I’m so polite).

I still often see designers who are in only one camp:

  • the old-school user interface designer who knows lots about workflow, user scenarios, goms (!) and interaction, but little about the detailed design of rich information spaces
  • the new-school information architect, who can design a site structure, taxonomy and controlled vocabulary, but doesn’t know a checkbox from a radio button

So I’ve been thinking about our future, and what skills we will need in the next x number of years (I’m not going to guess on a number) and think that much of our future lies in the bridge between the two. We need to be able to design amazing interactions that fit our body and our mind, and we need to be able to cope with the vastness and richness of information that surrounds us.

I was thinking about a university project I did last year which involved designing an in-car navigation system. I needed an excellent understanding of anthropometrics (eg how large are our fingers), visual perception (can I see the screen from here), attention (I’m also trying to drive), user tasks (what do I need to achieve my end goal). I also needed to use my information architecture skills to design the interface navigation (poor metaphor in this cirumstance) and search function.

Hopefully, this is the type of work that more of us will be able to get involved in – designing interactive systems that use rich information. To do this, we need to look at information architecture not through the lens of a website, but through the lens of an everyday device; which means that we may need to start thinking harder about getting involved in the design of those devices.

Designing in the car

Wednesday, August 25th, 2004

I designed a set of alternative home pages for a client site today. But I didn’t design them in the normal way, in front of the computer or at my desk – I designed them in the car, in my head.

I did the first design on the 45 minute drive home from work, and revised it on the 25 minute drive back to university (in between Amber’s endless questions about how everything works). Now that I have done the hard thinking work, all I have to do is do the computer work to document the designs.

Living miles away from everything, with a long stretch of empty highway, is a very good design tool…

A solution to creeping featurism

Monday, April 5th, 2004

A lot of people have written about the problems of creeping featurism – where products end up bloated and unusable due to the number of features and functions added to them. The solution most often suggested is to keep products slim, to do what they should do well, and to avoid adding features that a few people might need.

I’ve never found this suggestion practical – while the usability girl inside tells me that products with tons of features become complicated and unusable, the user inside says “don’t you dare take away some of my favourite features”.

So I do like the approach that Firefox uses (there may be other systems that do this as well, but Firefox is the one that triggered this thought). The core product is slim – it contains basic browser features and extensions are available to provide additional features. Out of the long extensions list for Firefox, there are only a few that I thought would be useful enough to install (mouse gestures, tabbed browser extension, paste and go). This is nice – I retain control of my product, it stays usable and I get features that I will use.

The implementation is still too geeky for more general acceptance. But if it were more user-friendly, with a neat way to explain and select features and a really simple install method, perhaps this type of implementation could be a good model for feature-rich apps…

I think it’s worth watching.

We don’t have to build it all

Thursday, January 29th, 2004

I was reading Lou’s post about an old article about spelling on ebay and the NY Times article about the same and noticed something that I thought was particularly interesting. From the ebay education guy:

“When will eBay get a spell checker?” His answer? “You go to a store called a bookstore, and you buy something called a dictionary.”

It reminded me that we actually don’t have to build every little thing that people think they want. Yes, a spell checker on ebay might be a good idea, but there are probably lots of good ideas that, when added up, would clutter the screen and make the whole thing a lot more complicated. Just like most of the difficult-to-use bloatware we have now…