I departed from the norm and rather than talk about the five methods I listed in my presentation outline, I went for something a bit more cheeky and light-hearted; the dangers of field research! The idea came to me because so many people I know who have done user or market research have told me stories about the weird and scary situations they’ve found themselves in out in the field. (In particular Stephen Cox and Raymond Van Der Zalm gave me some great anecdotes!)

I got some decent laughs so I was pretty pleased—and relieved—about that. I ended with a practical demonstration of the tongue in cheek self-defense techniques I had talked about, for which I must say a huge thank you to Gary Barber and Oliver Weidlich who volunteered to take part!

A few people have asked me if I’m going to talk about the five methods I originally said I would, and yes I will as there is obviously interest in those topics! Stay tuned.

No related posts.

The workshop is a new version of one I’ve run a few times before, updated with new examples and activities. The presentation will give a short intro to a few research methods that are not so common in the IA field.

Hope to see you there!

No related posts.

Seeing as I firmly believe that for every unpublished blog post there is one less bit of momentum keeping the interwebs spinning, I’d better put this up. And it’s interesting to look back at what I wrote two and a half years ago…

Day 1 started with a very inspiring talk by Bill Buxton. I think this was just the thing the industry needs, a bit of a reality check and a wake-up call. Firstly usability evaluation is not design and for that reason most people here don’t actually practice User-Centred Design. It’s all about data, rules, strict methodologies, large companies. They’ve even turned agile into something overly defined and bogged down (I have no strong belief either way when it comes to agile methodologies by the way). Bill’s talk about sketching as an important tool for the design process flies in the face of the artefact centric practice many Usability Professionals follow. No there’s no template for it, no there’s no software tool to do it, you have to use your brain! I mean the theme of the conference (“patterns”) says it all really.

This sounds really negative, but I don’t want to be. There are some smart and talented people here, but overall the industry is weighed down by strictness and illusions. Strictness in the sense that many people want some methodology to tell them what to do. I can understand that, but as Bill said, if you find yourself thinking that all the time (being scared of wining it) then maybe this isn’t the job for you. Illusions in terms of the discrepancy between literature and practice. A lot of the things published are not followed in practice (eg rapid, flexible approaches by clever people are replaced by limited, templated projects) and good practice is not published (eg using multiple design alternatives in usability testing). Then there’s the illusions of grandeur, like the way many practitioners think of what they do as some kind of scientific crusade and admitting there is some I-don’t-know-ness to it is an act of heresy.

For me, the best thing I saw at the conference was this talk. It’s a pity someone from outside the field (perhaps technically but really as far as I am concerned he’s slap bang in the centre of what we should strive for) had to be the one to say it. You can’t truly be doing UCD if you’re just evaluating, testing and documenting. This shouldn’t be about statistical analysis techniques.

I remember thinking that my approach to my work seemed at odds with how other attendees appeared to be working, and from the above it seems this annoyed me! Too many practitioners being more worried about following the ‘proper’ process, rather than actually thinking. And the post I did publish at the time, contains similar thoughts.

No related posts.

Unfortunately I couldn’t make it for the second day of the conference due to family commitments, which is a shame since the programme looked even better for the Saturday!

Our presentation on our new SuperRacing site (not yet live at the time of writing thissite is now live) went down well considering we had to cram everything we wanted to talk about into 25 minutes. The slides are shown below.

After two conference presentations in one week, it’ll be a while before I make another appearance, not to mention that I’ll be pretty brain dead for a while after the new baby arrives.

Related posts:

1. Design research presentation at Oz-IA 2009
2. Design research workshop at OZ-IA

I tried to make the topic a bit more interesting (read controversial) and I think it went quite well.

I covered two main topics, firstly I outlined why I think user experience (UX) should be prioritised over information architecture (IA), and then I discussed prioritising UX within the organisation.

IA vs UX

They’re the same thing aren’t they? I have certainly said as much in the past. I’ve also made distinctions between them. And depending on the level you’re looking at, both of these views hold true.

At a very high level, both IA and UX are forms of user-centred design (UCD) and would be more similar to each other than either would be to, say, cooking. And of course many people consider IA and UX to be synonymous (as well as a whole host of other terms such as IxD, ID etc). But for the purposes of this discussion, let’s define them as being quite different from each other.

What is IA?

A fairly narrow definition of IA might be something like the design of structure, navigation and labelling of a website or other information system. In other words, it’s very product-centric; it’s about the user interface, the system, the thing we’re designing and making usable. No doubt many people would argue with this definition or want to offer their own definition, and that’s ok. The point I’m trying to make is that if one was to take quite a low level definition of IA—one that is focussed on the interface—then you’re leaving out quite a bit!

What is UX?

The holistic user experience is made up of many different factors, and many different components. It’s more than just the IA, it’s more than just the UI, it’s more than even the product itself. It’s all the things that might make up the experience someone has with, or around, a product, service or organisation. A good UX will satisfy your audience, and keep them coming back.

If we expand this definition just slightly, you can see why UX is starting to merge into the area of Service Design and Customer Experience. We’re talking about multiple touch points and multiple media, not just the technical elements of UX in the Jesse James Garrett sense.

The contrast with the above definition of IA should be pretty clear.

Why UX over IA?

The purpose of this discussion is not to criticise IA (as defined above) or those that do not distinguish it from UX, but rather to highlight what we should be focussing our attention on. We should be focussing on the overall experience, not the individual aspects of the design of the a product. This includes the IA, but also the visual design, technical design and usability. Yes that’s right, usability is not the most important factor. I believe usefulness, appropriateness and the overall experience are much more important than usability.

So when we talk about prioritising UX, we’re talking about making sure what we’re building is useful for the people we are building it for. Does it make some aspect of their life easier/faster/better? Does it fit in with the rest of their lives in an appropriate and beneficial way?

When I say appropriateness I mean fitting a user’s “ecosystem”. You ecosystem is the (typically large) variety of sources from which you gather information that allows you to perform some function or role (Sonnenwald uses the term information horizons to describe a similar concept). These sources are often offline and used with little loyalty, killing the myth of the “one stop shop” that users will come back to like lemmings. This is a very useful perspective to take as a sense check for usefulness and appropriateness of proposed solutions. For instance, we might be tasked with designing a website, yet does that make sense? Not just ‘can we build a website’ but how realistic is it to propose the audience goes to a website to perform the task or action? Sometimes it just doesn’t add up and you need to re-think how you can sensibly be part of their ecosystem.

Of course there are times when a new product or service—even something as intangible as a website—can have a marked impact on people’s lives; change their ecosystem, change their habits, change the way they see the world. Good examples include Google, the iPod, Tivo and mobile phones; people do do things differently now because of the impact of those things. But I tend to think of these successes as serendipitous rather than calculated. Over time we have changed in response to products/services/technologies that could probably not have been predicted, let alone planned.

So to expect to design and launch a life changing product/service/technology is probably being a tad optimistic. Yet that is so often the reason given for ignoring the audience’s ecosystem: “this will be a market killer!”. It’s not that this doesn’t happen by design, just that only a small percentage of us are in this league. And it takes a hell of a lot of hard work to do this, it’s not as easy as saying your pride and joy will be a “one stop shop”. If you build it, they won’t necessarily come.

Ok back to the point, which is that in almost all cases you need to fit into your audience’s ecosystem and provide something useful, otherwise it doesn’t matter how pretty, clever or usable your product/service/technology is.

Hence I believe that we (those that might be willing to undertake this IA thing) can easily miss the boat if we’re not careful, and forget to meet our true, if perhaps implicit, objective which is to meet the needs of real people in the real world. If you’re just making it usable you’re not going far enough. If you’re just doing IA then you’re not doing enough. Similarly, focussing just on usability will ultimately fail.

Crucially you must understand who your audience is and what they need, want and do, before you can have any hope of creating something that is useful and that fits into their ecosystem in an appropriate way. You need to undertake research to find out these things.

Testing vs research

There is “usability testing” and then there is “user research”. These two activities are often confused and before we continue, let’s clarify.

User research is generative, exploratory and formative. It’s aim is to gain insight and inform the design process. That said, it doesn’t have to happen prior to or disconnected from the design process, just that it’s uncovering information that goes into design. In fact, this kind of research can continue well into the design process, especially if an iterative approach is being taken.

Usability testing on the other hand is evaluative, validitory and summative. It’s aim is to assess the outputs of the design process. That said, it doesn’t have to happen after the design process is finished, just that you’re taking stuff you’ve created and seeing how well it works, on many different levels. In fact, testing can take place from any point when there is something produced by the design process that you want to check or validate. Again, this is especially the case if an iterative process is being taken. (Oh and usability testing is not UAT)

The main similarity between the two is that they involve, nay require, user involvement.

On a practical level, there are many methods or techniques that are the same or similar between research and testing. The way you use them, or the value you extract from them, might be different, however. For example, interviews and focus groups are commonplace research methods, but they can also be used to “test” concepts, ideas and an understanding of the audience’s needs. Likewise, the “talk aloud” methodology typical of usability testing can be used as a research tool to learn about the audience and gain insight into how they use information systems, almost disregarding feedback on the actual user interface users are shown.

But what we’re talking about here is the research side of things; generating insight that informs design, and strategy.

Understanding users

A large proportion of the insight you’re gaining when you undertake user research is an understanding of users, or the audience as I prefer to call them. For example the kinds of question we might aim to answer include:

• Who is our audience?
• What are their goals, attitudes and behaviours?
• What are their information needs?

How do you discover all of this? Well there are a variety of methods you can use, ranging from face-to-face interviews and focus groups, through to “virtual ethnography” where you monitor the digital footprints of your audience to see what they’re doing online. And everything in between. There’s plenty of information on all these methods, just Google it, or you could attend one of my user research methods workshops.

Informing IA

Once we’ve got this understanding of our users, how do we use it to inform our UX strategy? And how does this trickle down to structuring the IA? Both excellent questions.

Let’s start with the strategy. Putting it simply, strategy is deciding “what to do” at a big picture level. User research can help with this in two ways: ensuring what you’re going to do is what people want, need and will use, but also ensuring that you going to do it to the right people. Once you have that sorted you would be able to go on to the IA.

Whilst at one level we want to ensure we focus on the UX, the useful, if we’re designing a website, intranet or other kind of information system, we will need to create an IA at some point. This is where you can get more specific and look at those three basics of IA I mentioned before: structure, navigation and labelling. Your user research can inform each one of these.

The structure of the information is something you can easily gain insight into through research. You might use card sorting to uncover how your audience see the content fitting together or you might get feedback on an existing categorisation scheme.

Navigation is closely related to both structure and labelling, however, a key research finding for navigation might be the outcomes of a task analysis that tells you the process users follow and on which you may want to model your navigation.

Labelling involves naming parts of your IA in a way which will allow your users to correctly understand what content or functionality is identified by that label. To make the IA as usable and meaningful as possible, the labelling used should reflect the words/terminology/jargon that the audience uses. A simple example can be found in most corporate organisations where the official vernacular might include the term “personal leave” but staff refer to it simply as “taking holidays”.

As such, going hand in hand with learning the language of users, you may need to unlearn the official language of the organisation for whom you are producing the IA. Or at least bridge the gap by somehow using both terms and establishing a process for migrating (“educating”) the audience, if that is appropriate.

I find that this quickly falls out of the research, because in order to speak with people effectively you have to arrive at a point where there is a common language between the researcher and the researchee. Ideally it is the researcher who should be actively bridging the gap and adapting their terminology to match the user. By doing this you need to recognise what words and phrases users use to refer to the problem space. If the subject you are researching has specific jargon associated with it, then this is something you need to pick up, and in most situations it would make sense to use that jargon when labelling the IA (assuming that the audience is familiar with that subject). The bottom line is: speak your audience’s language.

While research can inform the IA design process, it won’t necessarily give you the answers. The hard part is still to come up with a solution, which through no fault of your own might not be perfect. A great deal of compromise is often involved, whether it be regarding what can be implemented within the budget available, or a lack of support for taking on board the results of the research.

Encouraging user involvement

Ok user research is what we need. How do we get them involved? Encouraging users to get involved is relatively easy. Costs can be high if you outsource recruitment to a market research firm, but there are ways to cut this almost to zero if you’re willing to do some of the heavy lifting yourself. Such as, recruiting participants yourself through internal connections or perhaps using a survey or poll on your website (eg Ethnio).

You can even just grab people in the hallway, run concepts or sketches past them, rather than go for full on usability testing in a lab. The approach really depends on your objectives and available resources.

To help encourage this user involvement you should offer a form of incentive, either cash or some other compensation. But often the audience are keen to be involved, either because they want to help improve the product or service, or because they want to let you know how good/bad it is. Of course if you’re recruiting non-users or non-customers then this won’t be a factor, hence it’s usually a good idea to include both users and non-users in your research to see both sides of the fence.

Even before recruiting for a specific piece of research or testing, you should be open to feedback and suggestions from your audience. This might mean asking for feedback on your website, through an email address or a tool such as UserVoice. Or you could sign up to Twitter and listen to you users/customers. Or maybe you can just stop hiding your customer service phone number in the bowels of your website (in 3pt text).

No matter which approach to recruitment and research you take, finding or making opportunities to get in front of users is relatively easy. Encouraging your designers, developers and managers to allow user involvement is somewhat harder.

Many people (including Dan Szuc, Joel Flom, Jared Spool and Bruce Temkin) have talked about the idea of an organisation requiring a certain level of maturity before things like user centred design (or “service design” or “design thinking”) can take place. And user involvement is definitely one area in which this is quite evident. Sometimes an organisation or a team just aren’t ready to have user involvement.

It could be that they’re too focussed on establishing the business and getting products out the door; refining the user experience just isn’t a priority.

It could be because they are scared of what users might say (this is also a very common reason for the resistance to social media that many companies have).

It could be that the team(s) involved do not want to relinquish authority over the product or its design. They may feel threatened by users having input, because their colleagues might start to question their worth.

It could be that reward and recognition in the organisation comes not through creating the best product or service, but from cost-cutting or just doing what the boss says.

It could simply be because of the time and cost. It’s a popular view that everything slows down if we have to go and do user research. Or my favourite teeth-clencher: “this is an Agile project, so we don’t have time for research”.

The solution? IF you can sell the idea of user experience as a crucial part of the business, then the user involvement becomes a no brainer. You have to research and you have to test if you want to nail the user experience, and IF the organisation sees that bad user experience means loss of revenue, lower loyalty and higher costs then they’re going to want to make time and budget for those activities. Even in an Agile world.

Those are, of course, rather large IFs. Selling the idea of UX being crucial to business success is much easier said than done. Even in companies whose sole business is products and services that rely fundamentally on a digital user interface (websites, software, mobile etc), where you would think it’s be an easier sell. Alas, it isn’t.

This has become a hot topic in recent years, with excellent advice coming from such wise people as Dan Szuc and John S. Rhodes, to name but two. I’m not going to repeat all of their great suggestions for prioritising UX, but rather I’ll discuss a few tactics that I have seen work.

• Gain their belief – don’t expect respect and understanding, rather “gain their belief” (paraphrased from Mark Schenk’s great post on successful leadership). You’ll do this by showing you’re effective; make some quick wins, get a few runs on the board, prove why you should be given the time/budget/resources you need. This requires choosing the right projects to demonstrate value and impact.
• Communicate clearly – as I said before with reference to labelling, ditch the pseudo-scientific jargon and geeky terminology and speak the language of your audience, which in the case of selling UX is likely to be business and management types. This will probably require you to drop the ego (something which will work wonders with all the suggestion I’m putting forward here).
• Listen to the business – they might just tell you what they’re looking to get out of your relationship, thus giving you something to aim for and hopefully exceed. You may need to study up a bit in order to understand them and what they do; get your business groove on!
• Make deliverables visible – many products of UX work are very useful for (some might even say their sole purpose is for) attracting attention and generating discussion around the work you’re doing. Personas and concept models are two types of deliverables that immediately some to mind. Stick them on the wall in a high traffic part of the office. Make sure it’s clear who created them and that they welcome feedback. You don’t need to go so far as the life-size cardboard cut-out personas some organisations have made, but a nicely presented A3 poster that clearly communicates an idea or concept will do wonders for the visibility of the UX team and the work they do.
• Tell stories – they are a great way of breathing life into what can be a rather dry subject, tell stories of your success but also of UX challenges. The latter works in the same way as that old usability cliche: show management a video of usability testing where the user becomes frustrated by the product and they will probably get on board the usability train pretty quickly. Better yet invite key stakeholders to research and testing sessions. It can be tough letting them watch but you’ll need to get past that if you really want them to take you and your work seriously.
• Collaborate – break down the silos, drop the ego (again) and look for other parts of the business who have overlapping or complimentary skills and capabilities. A UX “Community of Practice” can be a good, low cost way to kick off this co-operation between different parties with an interest in UX. In many ways such a community approach can be much more effective than a dedicated UX team going it alone. And the cross-pollination effect can be a real bonus, not only in terms of gaining knowledge and skills from other teams but also because their reputation, legitimacy and respect can rub off on you, hopefully in a positive way.
• Be passionate – if you’re boring and act like the situation is dire, then why on earth would anyone want to encourage or support you?
• Find executive champions – I put this one last because ultimately what all these ideas are pointing towards is getting someone with authority on board and help you change the way the organisation functions (to a certain extent). Look for like-minded or sympathetic people who “get it” throughout the organisation, use them to help spread the word and build a case for doing things the right way. Usually these allies will be the result of demonstrating value through a project (see the first point above) but they can also be the result of networking performed “off the clock” so to speak. A born networker is thus a valuable asset for the UX team. If nothing else they can give the UX “elevator pitch” when an executive is more susceptible down at the pub.

No related posts.

It’s all very hush hush at the moment because we’re operating under an embargo, but the general gist of it is how user research can inform the design process for a product (in this case a website) that pertains to an activity that is normally an offline experience.

We’ll talk about how we identified the audience’s “information ecosystem” and found an opportunity for our website to fit in with that in a useful way.

We’ll also talk about the very different groups within that audience and how we catered for each.

Alun will then talk about the transition into design and go through the process we followed.

And if all goes to plan we’ll be able to unveil the new website resulting from all this work!

All this in 25 minutes, including questions :)

Update: if you promise to come along and watch our preso you can use this discount code: PK0265. Use it to get $100 off when you register for OZ-IA.

Related posts:

1. Oz-IA 2009

Last week I took part in Full Code Press, in which the team I was part of had to design and built a website for a not-for-profit client in the space of just 24 hours, competing against a similar team from New Zealand.

It was an intriguing prospect that didn’t fail to deliver some eventful moments, as well as a lot of frenzied activity. We didn’t win but that doesn’t matter I don’t think any of us were doing it for that reason.

So what did I learn from the event? Well it’s pretty obvious but I learnt it’s hard to cover that much ground in so little time. No so much because of the amount of work, but because of the group dynamics. The team had never met before, let alone worked together before, and we all had different style and ways of working. Making the absolute most of every minute of our time was difficult.

Our client was the NSW Disability Discrimination Legal Centre (DDLC) who promote and protect the human and legal rights of people with disability and their supporters through legal advocacy.

My role in the team was that of user advocate, and not surprisingly it was difficult to practice user centred design under those conditions. I had some grand plans for user involvement including making use of the many people passing by (the competition was held inside of the CeBIT technology exhibition) but there simply wasn’t time. We could have used card sorting to get some idea of how to structure the content so it would make more sense to users, we could have tested early prototypes, we could have tested the finished design to find usability issues, but there just wasn’t time.

Add to this the fact that the CeBIT crowd did not provide a good match with our primary audience (clients and potential clients of the DDLC) nor even our secondary audience (volunteers and donators–other than Bill Gates I don’t think IT folk are big philanthropists). True, they would have been better than nothing, but there just wasn’t time.

I had to take a heuristic approach. I think the name of the role I was given was entirely apt, I was the advocate, I had to stand in for the users (or who we thought our users were). Normally I would do this based on quite a bit of research.

Our client was vastly different that of the New Zealand team, being a legal organisation working to support people with disability who have been discriminated against. It’s a more serious organisation (not to dismiss the plight of the young people that RainbowYouth help out) and thus required a certain approach in terms or branding, visual design, tone of voice and functionality. For example,
social media is not that relevant to our client’s audience, but even it it was, creating and cultivating social media networks is beyond the resources and capabilities of our client at this time.

They also had a lot of content, and had done a great deal of preparation in terms of auditing their content and thinking about how to re-structure it all. (In hindsight I spent a lot of time managing content, putting it into the CMS and converting from other formats.)

Our first step was to talk to the client and get the dialogue happening. Our main contact, Peter, is deaf so these initial conversations were done with the aid of a sign-language interpreter (who was working hard!). It didn’t matter so much what we talked about at that point, it was more about getting a feel for each other and working out where to go next. Where we did go was into a discussion about brand and what they wanted the website to say and be.

I then did a quick analysis of the audience groups the client had spoken about. It broke down as follows: clients (those seeking assistance from the DDLC), givers (volunteers, donators and people wishing to help out in other ways) and info seekers (government departs, lawyers and anyone looking for reference material regarding disability discrimination). See the audience model sketch in the photo above.

Meanwhile the rest of the team got on with their own tasks; development got the technical stuff setup, content did an audit, design started on brand essence, and our project manager helped us all.

Rhonda (content) and I then took apart the content and reassembled it in a user centric model. This formed our draft IA, in post-it note form. At this point it was almost lockdown. If we had attempted card sorting it would have run out of time. Preparing the cards would probably have taken as long as doing our draft IA, and then we’d have to grab some people and run some sessions. Or we could have at least tested our proposed IA, but again, time just wasn’t available.

I did some revisions to the IA but we had to bed it down pretty quickly so that everyone else could work with the structure. Version 2 of the sitemap is shown above.

Next I worked on some user paths (process flows) for the donation, newsletter and membership functionality. This could have been stronger, but I think it was good enough to get by.

I then worked with design to whip up some basic wireframes, firstly for the home page and then lower level pages. Not a lot of fidelity was necessary as Alexi (design) had a pretty handle on it. During this we also refined the IA and brought it more online with our emerging audience model. This allowed to focus on the three main purposes of the site and lead to an elegant structure and home page that was commented on by several judges. The labelling came together during this whiteboard session too.

From here I started on putting finished content into the system, while dev and design finished building the site around it. The wee hours of Wednesday morning are a bit of a blur, they passed by quite quickly and we covered a lot of the monotonous ground during this time.

Barring a few technology hitches right at the very end, we brought the site together and met our minimum requirements just in time. The finished site can be found at: www.fcp-aussie.com.

All in all it was an fascinating experience. Congratulations to the Kiwi team for winning, but I must also congratulate the Australian team (from left to right in the photo below): Alexi Paschalidis (design), Elle Meredith (front end), me, James Farrell (back end), Rhonda Prentice (content) and Wendy White (project manager). I’d also like to thank our clients Natalie and Peter (and Sean his interpreter).

You can find more photos on Flickr and video on YouTube.

Tips for future FCP teams

• Meet up beforehand, to get to know each other a bit. The NZ team has a distinct advantage in that they travel over together and spend quite a bit of time together leading to the event.
• Plan your approach. Talk about who does what and when. You need to create a process that might normally evolve over years of working together. But you must accept it’s a compromised situation and that you won’t be able to do everything perfectly.
• Brainstorm anticipated functionality. It’s not hard to think of things most not fir profit organisations would want on the website. You might discount much of it based on knowledge of the audience (once the 24 hours starts) but at least you’ll be ready if it is needed.
• Choose technology that your techies are familiar with. Actually, more than familiar. They should know it well so that if problems crop up they can address them quickly.
• Be prepared for a lot of content. If your client has a lot to go into their new website, you need to have a strategy for handling that (perhaps strip it down or put some into PDF). The amount of content we had to deal with almost sunk us on the day.
• Focus on the website. You’re not being tasked with overhauling the clients business processes, just building a website. Sure, if you have time you might work on some way of tying the website into their CRM system, for example, but it’s likely you won’t have that much time!
• Alert the organisers as soon as there are any issues. This includes anything to do with the work environment, printers, servers, wifi, food etc.

Suggestions for FCP organisers

Firstly, great work guys, thanks for organising everything. Here are my suggestions:

• Maybe it would be better to pitch the two teams head to head for the one client. This would make for fairer judging by eliminating the possibility of having two vastly different clients.
• Maybe we now go world-wide: an ANZAC team takes on the Northern hemisphere?
• I’m not sure what benefits there were in being inside CeBIT, the exposure wasn’t great and nobody really knew what we were doing, and the lockdown also caused our clients some hassle. (oh and there was a cockroach in the toaster)

Related posts:

1. I’m on the Full Code Press team

There were some good things being said, and by real people who have done the hard yards. They’re not “industry luminaries”, but people out there in the trenches working out how to create effective intranets. Grounded and real are two words I would apply to the conference.

Then there was my presentation, a tad more abstract, but I felt it went well. Slides below.

I felt compelled to steer my presentation towards audience participation, if only because of the collective knowledge in the room; about half the room were presenting at the conference so I was learning as much, if not more, than I was dishing out. That’s the downside of being a consultant, you rarely get that rich experience that in-house staff have. Some great examples were offered by the audience, complementing my own examples.

There were one or two people twittering, you can follow the conversation on #smid.

Happy to hear your comments on my slides, either here or on slidehsare.

Related posts:

1. Strategically managing intranet developments
2. Using cultural probes for intranet user research
3. Design research workshop at OZ-IA

In my recent IA tutorial for OZCHI08, I told my students about performing low-fi usability testing on a draft information architecture. I introduced them to a technique which Donna Spencer called Card Based Classification Evaluation (CBCE) and is known to other people as tree testing or task-based information architecture testing (which really doesn’t have the same ring to it).

(Incidentally, CBCE is an evolution of closed card sorting but crucially different. I quite like Donna’s explanation for the need for such a technique from about the time she coined the term: Categorising information and finding it are two entirely different tasks, with entirely different cognitive processes. The only way to test whether a classification will allow people to find information, is to ask them to find information…You don’t learn it by asking them to place information in the classification. Hence just using closed card sorting won’t do.)

As usual, some people quickly tired of my affection for fiddly index cards and asked if you can do this electronically or even online. It reminds me of that line in Star Wars where the dude says to Vader “your sad devotion to that ancient religion has not helped you conjure up the stolen data tapes”…and you know what happened to that guy. Rather than crush their throats with my mastery of the Force, I explain that there are some advantages to good old cards:

• Cards are quick and easy to create and modify
• Cards remove the distractions associated with ‘using a computer’
• Cards allow a greater affinity between participant and facilitator
• Cards function consistently for all participants (whereas software may not)
• Cards can be made by anyone (eg don’t require special skills or software)
• Cards are cheap

However, I must admit there are situations when something more computery might be more useful, such as:

• You need to include remote participants (eg widely dispersed target audience)
• You intend to involve a large number of users in the testing (eg more than 20)
• You want to spend less time recording results into an electronic format (ok I’m reaching now)

You can use one of the many card sorting tools—either desktop software or online—but there are also a few dedicated tools. For example, Treejack which Sam Ng from Optimal Workshop showed at OZ-IA this year. It’s quite a nice tool and would do nicely for getting that all important user feedback on your design decisions early (and possibly later) in the IA design process.

Of course, one can use something like PowerPoint or Dreamweaver if one likes, it all depends on the resources at your disposal and the capabilities of your test participants—you might be a FileMaker whizz but there’s no point sending out a test app built in it if your users can’t open it.

Feel free to leave a comment below if you have any other suggestions.

No related posts.

(Sample size is 206)

It was a surprise to see the US ranked number one on the list, I was expecting Australia to be the highest with possibly the UK as second runner up. Was probably my post to several US-centric mailing lists that produced this result.

By the way, I gave up on the rubbish charts created by Excel pretty quickly, and went looking for a better option. I’ve used Widgenie.com for this chart and it seems to meet my needs quite well. Although I’d prefer not have to insert script into my posts.

This is a mere snippet, I know. As and when I get the time to release a bit more I will do so.

UPDATE: the Widgenie charts use Javascript so if you’re reading this in an RSS reader, you’ll probably have to click through to my website to view it.

Related posts:

1. How not to run a survey
2. IA for Agencies survey now closed
3. Designing WordPress 2.7 by survey