Hands up in the air!

The turn out at last night’s ACS Forum for my presentation on user-centred design was pretty good!

(You can download my slides from Slideshare)

And there were lots of questions following my presentation on user-centred design, methodologies and tools. Here’s a summary of some (that I can remember) below:

How do you ensure you sample the right users?

Sometimes the people you think are your users arn’t the actual users of your system. Identifying all the stakeholders involved and their roles in the project and its outcomes is a good place to start a user-centred design process. You can do this by performing analysis to determine the correct audience segmentation and then documenting the needs, wants, attitudes, and behaviours as personas. This will give you the best idea of where to look for what users to participate in your user-centred design activities.

On occasion, there are specific stakeholders you will need to include in user-centred design, and sometimes these are the most vocal, but if you remember that what you’re doing is also about change management, then the benefits of invovling them in discussion about where your system is headed is obvious.

When do you know when its time to stop doing prototyping?

“It depends”, is probably the most logical response.

In some instances, it’s appropriate to prototype the whole solution. Some movie makers do this for their movies to help them sort out camera angles in complicated shots. The work that I did involving semantic analysis required that I prototype the whole solution. This was a very tricky piece of analysis and in order to sell the solution I had in my head to everyone, particularly to get funding for it, I prototyped the whole thing. This made the Solution Architect very nervous, as it suggested certain technologies be employed without consideration or consultation with developers. But through my efforts I was able to sell the solution even to the most skeptical of potential users. They loved it so much that they became the system’s advocates even before a single line of code had been cut.

In other instances, you could stop prototyping when the users are satisfied that what they’re seeing reflects what they want in a system. I’ve even had meetings where the business have signed off on the requirements based on a high-fidelity prototype, rather than having to read a mountain of business-level requirements.

Ultimately, it’s good to use them throughout the project to involve users in its development.

Can’t computers do all this?

Some techniques, like storyboarding and prototyping, can indeed largely be automated and spit out lovely UML at the other end. The problem with this approach, however, is that it often removes the user from the cycles of our validation processes — the very thing we’re trying to put back-in by using user-centred design.

The discipline of Knowledge Management reminds us that knowledge transfer is a social thing between people. User-centred design leverages this by explicitly involving people as part of the solution validation process. The benefits that are had from this process, therefore, are found in change management. Automating it just won’t deliver a vision for the project, or help with change management.

Can you use this approach with products?

Marketing companies use user-centred design techniques all the time. I even remember as a child being approached off the street to participate in icecream testing — a company had a new flavour and they simply wanted to know what people thought of it. It wasn’t the final version of the icecream, but it was enough to give people a feel for how it looked, how it tasted, and how it might be improved upon.

Where does it save time?

Is system development about 80/20? I think I’ve seen too little analysis up-front in the systems development projects that I’ve been invovled with over the last 10 years. It seems almost to be a rush to get a set amount of requirements and then build in the quickest amount of time. I’d say it’s more 40/60.

Certainly, a user-centred design approach does require more up-front analysis. I’ve found that it ultimately helps identify the tricky bits of a system and help to sort through them. You can even ‘play’ and try out ideas to see if they work. On one recent website project I was on, I had a few different ideas about navigation. The users like the navigation on the top, but I wasn’t sure whether it would work, so I prototyped it both ways and, discovered, that puttingn on the left-hand side just didn’t work. If I had’ve waited til the CMS builders came in, we would have had to do lots of rework, costing time and money.

Do you have any questions from the presentation? Just make a comment below

M