The second and final day of UX Australia began with the inspired wake up working session, and continued with streams of talks more focused on showing both sides of the designer-client relationship, and insights on UX related fields ranging from AR to retail.

Morning Wake Up Working Sessions

In what was a fantastic idea from the organisers, the first session of the day consisted of workshops led by Jay Rogers (Traditional hand-skills for sketching), Gary Barber (Keeping sketching real), Caronne Carruthers-Taylor (Sketching user journeys), Symplicit (Wake-up design challenge), Different (Visioning) and Westpac (Touch-point card game).  Attendees loved the concept as a creative way to start the day, and we hope that other conferences pick up on the idea in the future.

Workshops - Westpac Touch Cards, and Jay Rogers teaching sketching

Real world challenges and how we tackled them, shown from two perspectives: us and our client

Michelle Gilmore, Wendy Barnao

This presentation delivered on its title with Glimore (UX designer from Neoteny) and Barnao (client side Project Owner for Asgard Wealth Solutions) sharing their perspectives and experiences of a recent challenging yet ultimately highly successful project. Barnao gave us a rare insight into what it feels like to be taken on the HCD journey for the first time and the role she played in helping the design team come to terms with, and gain access to, the complex world of financial services.

Gilmore stepped us through the lessons learned navigating the complex project and its multiple stakeholder agendas, challenging us to take more responsibility for ensuring designs live beyond the handover. How to work better with (rather than for) our clients was a recurring theme of the conference and this presentation took it one step further – sharing real obstacles faced from both perspectives, as well as strategies for doing better next time. (Many in the audience thought client/designer duos should be a regular feature). To keep the conversation going Gilmore’s team at Neoteny have created www.challengepile.com as a place the design community can capture and share project challenges and solutions.

The Value of Asking Why?

Dan Szuc

A question of value - remember when this was valuable?

Former Melbourne boy Dan Szuc literally opened up the family treasure chest with the start of his talk on value, having cleaned up his family home while here to find such relics as a (fully working) 1950s radio and a brick phone (that many in the audience found oddly good to hold).

In his highly interactive talk, he challenged designers to consider the value of their products they work with, what they do, and the need to design for things such as:

• value (self > product > environmental) and happiness “It’s hard to introduce happiness in your products if you as a designer are unhappy”
• knowing when to say no as cycle company Franscesco Betelli does
• embracing failing fast and keeping teams small in order to do so, as Google does
• creating a shared language and values between engineering, marketing, design

Szuc finished with the inspiring quote from Joshua Porter on 52 Weeks of UX

Creating long lasting value does not happen by accident. It is the purposeful application of sensible design for real people.

Creating mobile experiences that matter

Rod Farmer, Anton Sher

Farmer and Sher delivered an energetic, fast paced presentation demonstrating the acrobatic UX moves they performed in order to get the award winning 3 Mobile iPortal out into the world in 6 weeks, in total secrecy. While Farmer shared key design principles and the story of the project Sher shared the low down on the actual portal design. This presentation was packed with practical “how to” tips for designing for mobile (it’s about the total experience not just the UI), as well as being living proof of what can be achieved even under the most extreme constraints via “Mad Max UX” – despite all the challenges the app meet annual traffic targets within 4 weeks.
Take outs included:

• Mobile experience is about interaction between people, place & platform
• Think “situational planning#” – mobile experiences unfold over time, people snack, stop, start, change and get distracted – completely different to a sedentary desktop interaction
• Focus on personal over personalisation and context over features
• Always design at scale

#A big field but situated action texts from HCI are a good start point for the theory behind this e.g., Suchman’s seminal work or Jakob E. Bardram’s PlansAsSituatedAction.pdf

The Secret Life of Deliverables

Anthony Quinn
What’s a deliverable? Quinn reflected on his (and many “friends’”) experiences with the issues of deliverables in the black box of “large organisations”.
Some of the gotchas they keep in mind is the design maturity of the company (taken from B+D), implicit objectives, and clients not knowing how to critique (they get around this by both combining Jesse Jame Garrett’s Elements of User Experience to frame the deliverables, and the RASCI model -Responsible, Accountable, Supportive, Consulted, Informed – to help stakeholders understand their level of influence in any design decision.)

They concluded that deliverables are:

1. Produced to influence an outcome;
2. Recognise & respond to content
3. Draw out implicit perceptions, objectives/expectations
4. Manage stakeholder explicitly, continually/consistently
5. Ensure users of deliverables can articulate intent actions required to achieve desired outcome
6. Observe. orient, respond to change

The Westpac team are also creating a prototype toolkit of these learnings, which should be very interesting to see.

Emerging a content strategy from user research

Scott Bryant

Scott Bryant

Byrant turned the spotlight on his relationship with lorum ipsum asking how user research might be better applied to informing content strategy (not just navigation, design and interaction).

Taking principles from Halvorson’s book as a start point Byrant took us backstage into one of the most content rich online contexts – news – sharing video interviews with the people who “make content happen” within News Digital Media (NDM). Bryant used questions about the context of content, the use of user research and what content creators in his organisation were influenced by to investigate the role and nature of Content Strategy in this context.

He also showcased some of the experimental approaches to testing and measuring people’s experiences with content being taken by the USiT team at NDM such as clicktale.com, FB Like & recommend and www.tynt.com.

Defining the recipient journey: The role of software to support hearing restoration at Cochlear

Shane Morris, Toby Cumming, Jane Cockburn

Speaking from both the perspective of client and designer, this presentation showed the potential of UX to be used in conjunction with innovative medical technologies. Cochlear, an Australian company who create world leading hearing implants, identified an explosion in need for their devices in the near future, but a blockage because the current software requires specialist training for clinicians to use.

Done in combination with Different and ACID, the agile-like project  – -   is still in progess, but so far has been very successful. The lessons they’ve learned so far are:

• Use the appropriate tools: the team had initially thought they’d use a living spec doc (a Sketchflow prototype), but realised that it became too unwieldy to update and reverted to a combination of paper for general testing, flash for key screens , and a standard document for all details.
• Team involvement: having personas on the wall, and bringing developers into testing has helped them get real sense of empathy. The best story the team had was of one of their developers role-playing the part of a six-year old girl, daydreaming and all!
• Stakeholder Engagement - UX process has helped engage stakeholders (marketing in diff. countries). Cockburn called this “crossing the bridge” with a common language. An unexpected side effect of creating personas was that they got adopted by both marketing and management to the point that they were all would refer to them by name.

Activating Customer Centric Culture

Ian Muir, Ean Van Vuuren
In this seriously meaty presentation Muir and Van Vuuren told the story of Westpac’s (ongoing) transition to a customer centric organisation. Van Vuuren described the journey from the business perspective – a move from ‘selling’ to ‘buying’, (i.e., how do customers buy houses/manage mortgages/credit cards…). Muir gave us the “how to” behind the process describing the steps along the maturity model and emphasising the need for a robust strategy that can withstand challenges from skeptics. This generous presentation demonstrated the value of a customer-centric model through very visible ROI including product uptake, such as their iPhone app which has done $1.1B worth of transactions with over 300,000 customers since March this year. Van Vuuren reflected on the inevitable resistance to change but highlighted the richness of rewards when things were done right: “whenever I’m feeling down I read the comments about our iphone app…”.

Designing for Touch Screen Experiences

Oliver Weidlich
Beginning with a poignant story of his elderly grandfather using an iPad, Weidlich led the audience through a useful primer on touch screens, and some pro tips.

Starting with some background information about touchscreen devices (most primitive touchscreens were resistive, but now being replaced with iPhone style capacitive screens), he gave the three key questions to keep in mind – screen size, screen distance, and available attention (these devices are rarely used without distractions). He also emphasised that tablets not only have new ergonomics to computer and mobile, but are also encouraging new behaviours (use in bedrooms and kitchens). Because of this, help screens (usually a sign of a bad UI) are standard to help users learn the capabilities of touch applications.

Based on his experience, he gave the following suggestions:

• Avoid outer positions (these may be accidentally hit when held, and generally aren’t as responsive as the centre
• Relax muscles (Latency – minimise scrolling with hub & spoke design
• Optimize interface for taps rather than swipes or drag)
• Use touch interaction guidelines such as http://lukew.com/touch , and http://swypeinc.com (a suggestion from the audience was http://gesturecons.com)
• Make visual feedback clear: as there are no hover states as we have in web.
• Optimise for one finger (but consider multiple)

Above all, his two big takeaways were appropriate target size and placement are key, and (as in all interaction design), sweat the details.

For future inspiration, he suggested the Instapaper guidelines and concept UIs such as Skin, haptics work, roll up screens, and finger-behind interfaces.

Joe Sokhol

Nailing it down: Specifying experience design so it can be built

Joe Sokohl

Delivered with some serious southern style Sokohl asked us to reconsider the role of specifications – suggesting that while the move away from massive inhumane 200 page spec docs is a good thing, it’s not about ditching the notion of specifying design altogether (especially in complex/remote work environments).

The core message was: make sure that specifications actually do their job. Sokohl argued that anything that impacts user experience is the domain of the UX designer, and it’s up to us to communicate those specifications effectively – that is: “just enough detail to enable the developer to understand the UX designers intent”. Sokohl pointed out the common disjuncture between what we deliver and the work that has to be done, providing some alternative approaches to conventional specs such as annotated wireframes and sketches and advocating for embedded specifications which provide the detail in the context of the design.

AR-UX: The generation of the pervasive User Experience

Alex Young

Young got beyond the hype of AR (she explained the field has exploded in the last few years but mainly in novelty ways such as brand presence) to talk about its various modes, constraints, and opportunities.

Of the types of AR:

• Public is generally used for art exhibitions etc. The Lego kiosk AR box was a mixed success, as people didn’t know how to activate the experience (some had markers missing, others just didn’t get it)
• Intimate (PC) is good for home – GE Ecomagination was a success at being entertaining, but an unexpected side effect was that schools loved it as it encouraged kinaesthetic learning
• Personal (mobile) may be browser based (e.g. Wikitude, Layar, Geneo) or object (Google Goggles) – great for finding places or gaming but main issue is discovering content.
• Private (ubicomp) – the standard sci-fi goggles – is virtually unused at present, however Young sees a future in this (see yesterday’s talk on biofeedback).

The challenges are very similar to those in mobile – context anywhere, rapidly changing technology,  new affordances and users, and utility – but with added ones of physicality (T-Shirts are problematic as people are different sizes), and expectations (she pointed out that Hollywood is now making near-future films such as Iron Man which makes cinematic quality AR look like it’s here).

Designs that ship: New tools for ensuring your UX work reaches its audience

Matt Morphett

Morphett’s presentation extended the theme of working better with our clients sharing tips, tricks and props from a recent project. Morphett presented a number of different tools including the User Stakeholder triangle used to map out with client various project motivations across the three core perspectives of business, architecture and users (check out the templates). The method encourages representatives from the three different stakeholder groups to recognise the inherent dynamic between their particular perspectives, and gives them a tool to negotiate productively around the different priorities and how they impact the project. Public posters at the client’s office showed the areas of focus for each week and fun, physical props including a Magic Wand (representing users), a squeezy spanner (representing engineering), & a Magic 8 ball (representing business) were employed to help stakeholders stop, reflect and consider the motivations and implications of different design decisions.
Key messages included:

• Provide a framework that helps to get the problems out on the table and lets all stakeholders work through them together
• Ask: Who could undo a design? Go as high as you can & get them involved
• Get key stakeholders from Architecture, Business & Users seeing the dynamic between their different needs & contributing to the solution

Creating innovative retail organisations

Richard Beaumont
The conference track finished with a fast paced presentation by Beaumont that documented his learnings from working with retail chains Tesco, Coles, and 1st Choice. The sheer volume of were  impossible for even the most ardent live-tweeter to capture, but what came through was that many strategies in retail are known to user experience (talk in the stakeholders’ language, consider all aspects of the journey and roll-out), but on a far greater scale (Tesco now works across the UK, Europe and Asia).

• Tesco’s innovation strategy is – consistency, having the best people, plans, objective, projects (they demand project management experience of all leaders), succession, sharing insights.( Tesco went to Asia, learned from hypermarkets there, brought findings back, learned to work on different scales)
• The paradigm shift for different scales -  particularly from big to small  – is hard. Most Tesco small stores didn’t make money for 2 years, learned from results.
• Bottlenecks are dangerous and inevitable (people lie about metrics)
• With competitor analysis, when taking photos in competitor’s stores “if you haven’t been thrown out, you haven’t taken enough pictures”
  Documentation needs to be clear, updateable, highly visual, that cover the whole shopping journey (this includes front and back, hours of ordering etc).
• Talking in stakeholder language is key – for example putting brand decals on the supermarket sold over the marketing director Stakeholders may often not ‘get’ visuals – 3D cutaways were most successful (3D models helped the designers more than anything).  3D videos get sign off, but often bring up questions for internal departments (too high-fidelity)

Other nuggets that came out of the questions were:

• Shops work with “passion items” (e.g. you need sponge to make a trifle) and make sure these are always in stock.
• In terms of shopping science, Paco Underhill’s company Envirosell is still the best around, and those who like his book Science of Shopping will be interested in his upcoming title What Women Want

if you haven’t been thrown out [of a competitor’s store while doing research], you haven’t taken enough pictures.

The day finished with giveaways – Morgan Kaufman and Sitepoint books, an iPhone and iPad, and even trip and flights to UX Hong Kong, as well as thanks to all involved (for the record, this was the rare conference where the wi-fi never went down, and where free espresso coffee was provided aplenty) and many taking one more chance to enjoy Melbourne hospitality.

For more resources, check out the the twitter stream, Flickr sets, and many sketchnotes available.

—-

Header image by Steve Baty
Joe Sokhol image by Alex Walker
All others by Penny Hagen

Melbourne set out to impress for this year’s UX Australia, held in the beautiful Langham Hotel. Year two of the conference had a feeling of building on the work from the inaugral event with confidence and assurance -  (even if the day began with many recovering from the pre-drinks before).  Some recurring themes of the day were business and design, wicked problems, and the emotional side of user experience, with the community coming to the fore with an active twitter stream and visual notes.

Keynote – The Dawning of the Age of Experience

Jared Spool

Jared Spool's Range of UX Skill

“Saying a website is ‘usable’ is like saying dinner was ‘edible’

Spool kicked off the conference with an entertaining and wide ranging talk (who knew that there were people called chicken sexers?) that covered user experience and business, design knowledge, and ways to create great UX.

He began with a rundown on the iPod/Sundisk/Zune scene (market share 75%, 7%, and 5% respectively), and a breakdown of the reasons – despite the iPod having inferior hardware and a troublesome OS, they have won on their service system (they are the top digital seller of music/third overall, and are the only manufacturer to have service stores) and an attention to brand.

He also touched on similar success stories (Netflix has far overtaken Blockbuster, and attracts new customers largely through their existing ones evangelising it), but more interestingly some failures, to highlight the perils of favouring user experience over business:

• Big Box Retailer lost 20% of revenue after spending $100k on redesign, took 3 1/2 years to recover.
• A 1,700 person law firm moved from static HTML to a Sharepoint site – no one could change anything, didn’t bill for a month (~$4m), and employees were near revolt
• An information site changed the findability from 4 clicks to 1, which would have been good  … except that the site make money on clicks! They had a 40% drop in page views.

Spool also touched on how design decisions can’t always be interrogated, as while research is useful, designers – like chicken sexers, sushi chefs, and midwives – often “just know” solutions through experience (see his related Johnny Holland post on Hands and Brains for talk on this as well). The intriguing suggestion here was that we should maybe consider the idea of UX apprenticeships. This becomes more important when we realise the range of skills involved in UX (see diagram on right).

Spool suggested we ask three questions to find great UX:

1. Vision – “can everyone on team describe experience of using the design 5 years on?”
2. Feedback – “in the last 6 wks, have you spent more than 2 hrs, watching someone use your or a competitor’s design?” Studies show that exposure time impacts success
3. Culture -  “In the last 6 weeks, have you rewarded a team member for creating a major design failure?”. Scott Cook, the CEO of Intuit, holds ‘failure parties‘ – he presents an award to the recipient, teases them for 2 minutes – and then spends the next 28 unpacking what they’ve learned from the project.

and summarised that successful UX:

• integrates users & business,
• is learned but not open to introspection,
• is invisible,
• is cultural,
• ….is something we’re still learning how to do (and we’re getting better everyday).

Defining Experience Strategy with UX Designer as Protagonist

Anthony Colfelt

Colfelt gave a number of memorable metaphors for UX design in his presentation, backed up with his work at UX consultancy Different. Beginning with the solar system of UX (currently tech is the sun, circled by the business, which is circled by customer experience), he suggested that to counter this and allow user experience happen earlier in the project management process, UX designers should be like the ultimate protagonist – Arnold Schwartzenegger.

His key takeaways were that experience research should be like a shield (no holes, scientifically implemented) as it could then be used to avoid costly mistakes downstream.

Designing wide in Government: A recipe for doing the design of very, very complex concepts that impact on society

Darren Menachemson

To give a sense of the complexity of designing wide in Government Menachemson started with Horst Rittel’s notion of wicked problems. Menachemson gave insight into what is involved in tackling incredibly complex design spaces (such as systems for dealing with the whole health of a patient over a life time). Wide design starts with wide outcomes requiring us to focus on products and service in the contexts of systems – rather than a micro view (interfaces, interactions, etc). Many of the points resonated with essential service design principles, but a key (differentiating?) aspect  was illustrated through the perspective taken in the Citizen Journey map by the Design Council: the start point is the citizen’s journey in life (from which we can identify and leverage the points of intersection with government), not the citizen’s journey with the government (big big picture!). His tactics? : work collaboratively (but make sure this work is somehow accountable and has influence), stay away from the detail (for as long as possible) and cultivate a tolerance for ambiguity.

Getting new blood from old stones: How to get new insights from old data

Stephen Cox

Cox shared a different way of thinking about research and how it ties into our everyday work in this fantastic presentation delivered with some great home style video humour. Prompted by a need to bring vendors working on customer research projects up to speed with knowledge already possessed by Westpac, Cox shared how he mined old data (10 years worth!), found new high level insights and patterns and shared them through tools like bare bones personas. Rather than sticking to the status quo of research on a project by project level (tactical) his “insights framework” helps the organisation identify and seek operational and strategic insights from existing and future research data. This was also a call to action for design research vendors to get more strategic with their own expertise – research is cumulative, so start embedding strategic questions within project-level research that can help to inform and develop higher level knowledge.

Design Thinking – Is This Our Ticket to the Big Table?

Iain Barker

Barker started by asking the audience whether many called themselves either Design Thinkers or Service Designers (both only had a few hands raised), a fitting start for a talk that looked at the current business – but not design – darling, “design thinking”. Sharing a number of resources both for and against the argument:

• the IDEO definition
• Helen Waters at Design Week 2010 “For now, the business community seems to have the ball, and it’s running with it. But designers can’t afford not to be a part of this conversation”
• Kevin McCullagh at the Big-Rethink 2010 “There’s something odd going on when business and political leaders flatter design with potentially holding the key to such big and pressing problems, and the design community looks the other way”.
• The rather concerning statement from Bruce Nussbaum that “CEOs must be designers“
• Don Norman’s “Meanwhile exploit the myth [of design thinking]. Act as if you believe it. Just don’t actually do so.”

Design Thinking and Experience Design - can't we all just get along?

However, backed up with some amazing stats such as that shares in design-led companies outperform others in stock led indices by 200% ) he urged designers to perhaps just do design thinking work, (and be prepared to have to fight for design processes and against indoctoration) even if they’d rather not be called design thinkers.

Design Secrets Revealed

Todd Zaki Warfel

Originally called “the right way to wireframe” this rare behind the scences glimpse of what Ux’er’s do all day was was prompted by the lack of visibility around UX work. Unlike visual designers who show case on sites like dribbble.com or developers using Github, we’ve never seen the wireframes of the likes of JJG or Peter Moriville (though we have now!). Todd Zaki Warfel,  Will Evans, Fred Beecher and Russ Unger took up the challenge – shut up or nut up – to “pull back the Kimono” and expose their work practices.

What we learnt:

• They never work to requirements (“that’s for monkeys”) – use methods like the task analysis grid instead which put things in context and enforces a prioritisation
• Sketch, sketch and sketch some more – as a team – do it fast then (live) prototype
• Pitch and critique at every stage, with clients (practice can be required & as @Sandie_lewis tweeted “critique is about how well a design meets the design goals. Not about what you like or don’t”)

Check out the slides and the 4 minute video of the whole process below or with related videos:

Designing for Biofeedback

Erik Champion and Andrew Dekker

Champion and Dekker’s presentation on their research into biofeedback [academic paper, PDF]was an insightful look into future interfaces. Their study (as well as talking about zombies and psychology, the uncanny, and current biofeedback devices) adapted Half-Life 2 to adapt to skin (sweat) and heartrate feedback from users wearing a glove. The game used the feedback to change the game in a number of ways:

• The scene was monochromatic with a low heart rate, vivid at faster rate, and red with high stress
• Deliberately keeping breathing rate slow made the user see through walls.

Tests shows that gamers preferred the biometric version of the game. Champion and Dekker suggested that future applications for this include gaming, meditative purposes, and even public spaces.

Beyond Frustration: 3 Levels of Happy Design

How much happiness can you design in? Dana Chisnell urged designers to think about designing for happiness. In a presentation similar to her UX Mag article of the same name, she outlined what she considered her 3 levels of happy design:

1. Pleasure – a pleasing awareness, the of course, relationships, satisfying. Don Normal calls this visceral. She suggests that they have ‘treats’ [or Easter Eggs] and are thoughtful, and gives http://tripit.com , http://mint.com , and Virgin America as examples.
2. Flow – Understanding, contentment, time stops – immersion, key strengths emphasised, trust
3. Meaning - reflectiveness, commitment, belonging, contributing, making a difference (part of something bigger than you) – examples include http://zipcar.com

Change Agents at Object Gallery: A multi-disciplinary experiment in interactive physical installation design

David Gravina

Change Agents project

Can design change the world? Yes, but not without a road map and some tools. Gravina shared the public kick off of Digital Eskimo’s new Change Agent’s project (building on the theme of wicked problems introduced by Darren earlier) – the goal is to create an open source & free to share toolkit to help designers tackle the big issues. Digital Eskimo attempted a public form of collaboration with other designers via installations at Object Gallery and then ACMI. It turns out that post-it notes are a big hit for gathering ideas even in a gallery context! Gravina reflected on the opportunities and pitfalls of trying to engage people in big ideas in such public spaces and the dangers of giving people free reign with texters! While the ideas people contributed to the physical installations were intriguing, the real results were in getting other designers and architects on board the Change Agents project.

101 things I (should have) learned in interaction design school – the sequal

In the follow up to the hilarious-but-strangely-informative UX Australia 2009 talk (where they took rules from Matthew Frederick’s book 101 Things I Learned at Architecture School and attempted to apply them to interaction design), Morris and Morphett upped the ante in every way possible …. from a DIY (!) money grabbing machine on stage, to a host of 101 Things books to work from (now architecture, film, fashion, business, and culinary school), a Windows 7 app user-testing-from-hell session, and numerous mentions of the trials and tribulations of their http://ux101.com site.

Chaos reigned at UX Australia when Matt and Shane took to the stage ....

That said, most of the rules pulled from other design disciplines, ranging from customer allergies to studio locations proved fairly easy to translate:

• #77 from 101 Culinary: A customer’s allergy is a chef’s problem. Translation: know your users test a lot.
• #45 from 101 Film : Studio or Remote (for locations). Translation: testing in the field versus testing in a controlled environment
• #63 from 101 Film : Help the audience keep track of your characters (have original, pointed names). Translation: don’t have a flat unprioritised visual hierarchy;  think of user paths and  anoint landmark pages to  help people through your site.

—

Jared image by mssuec

Matt and Shane images by wheelyweb and NathanaelB

I really don’t like to go grocery shopping. There are a lot of things I don’t like about it, but especially trying to choose the “right” product. There are just too many choices. Do we really need this many types of mustard? Unmoderated usability testing tools used to fit nicely into the old general store. There were just a few tools, and the differences were obvious. Recently, unmoderated usability tools have begun to fill an entire American sized grocery store. In this article I would like to help you walk down some of the aisles of this store, and provide a little guidance in how to shop for the right unmoderated usability testing tool. Think of me as your “personal shopper”!

Important note: In the first version of this article we’ve mistakenly shared wrong information regarding the services that Webnographer provides. Webnograper is a service that carries out studies that range from 100 to over a 1.000 people, resulting in both qualitative and quantitative research data. It provides many different services.

Before we enter the grocery store, there are few ground rules I want to lay down. First, we are only shopping for unmoderated usability testing tools. This does not include remote moderated testing tools such as Morae, WebEX, or GoToMeeting that can used to run 1:1 usability sessions. We are also not shopping for online survey tools such as SurveyMonkey and SurveyGizmo. These are certainly helpful in collecting feedback from large numbers of participants, but there is typically no interaction with a product or design. We will be focusing on tools that researchers and designers can use to collect usability data from end users in an unmoderated way. These tools essentially involve setting up a study, launching it to a small or large number of participants, and then some conclusions might be drawn regarding the usability of a specific product or design. Before we enter the store, I apologize in advance.

There are some tools that I will miss or may misrepresent. The tools are changing everyday in terms of functionality and pricing structure. This is only a fuzzy snapshot in time. With this in mind, now let’s enter the store. As you can see from the “floor plan” below, there are two main sections of the store – quantitative and qualitative-based tools. Quantitative-based tools are designed to collect data from a large number of participants, with a focus on UX metrics such as task success, task completion times, click paths, abandonment rate, etc. These are the tools you need to run a benchmark usability study or compare subtle design treatments. The other side of the store is the qualitative-based tools. These tools are essentially a substitute for lab or remote-based usability testing. These tools emphasize collecting feedback from a small number of end users in a quick and dirty fashion. You may or may not be able to actually derive any metrics, but at the very least you will gain some insight into the most significant usability issues and hopefully make the right design decisions.

Quantitative Tools:

Full-Service Tools

There are only two full-service tools I am aware of – Keynote’s WebEffective and Imperium’s Relevant View. Both of these tools provide you the flexibility you need in terms of setting up an online usability test and the data it can provide. You will have a tremendous flexibility in the study design including the use of conditional logic, blocking, and randomization.  But, what sets these two tools apart from the other quantitative options is the support you receive. Experienced researchers will assist in designing the study, piloting/launching, and data analysis. Of course, this support does not come cheap; an individual study can easily be $10K and up. There is no set price; it all depends on the individual characteristics of your study and how much help you need. But, you will get peace of mind that the study was conducted in a highly professional way.  You can just think of this as the “prepared food” section of the store.

Self-Service Tools

These three self-service tools range in the degree of flexibility and analytical capabilities. UserZoom has many of the same set of functionality as the full-service options, but at a fraction of the cost. A typical usability test is about $3K, or $9K for an annual license. Loop11 is much more streamlined, in that it does not support functionality such as conditional logic or randomization. Loop11 is easy to use, very inexpensive ($350 per study), but it is very basic. If you need to collect various UX metrics, you want to visualize abandonment or click paths, or really do anything beyond tasks and simple questions, you should consider UserZoom. Bottom line though, and of these three tools will help you collect solid usability metrics at a reasonable cost. They also offer technical support as well as access to customer panels.

Card-Sorting/IA Tools

These online tools allow researchers to create or validate the information architecture for any website. The folks from Optimal Workshop have created two valuable tools. One tool, OptimalSort, is a cardsorting application, in that it allows participants to sort items into groups, and provide labels for those groups. It then analyzes the data from all the participants, and determines the best groupings for the items. This is sometimes referred to as an open card sort. The Treejack application allows the researcher to validate an information architecture. Participants are given a set of tasks, and then asked to select the correct location for each task. Task success and time are measured as a way to evaluate and validate the IA. This is sometimes referred to as a closed card sort. WebSort offers very similar functionality as OptimalSort. The pricing for all three products is very reasonable, with single studies running about $100.

“Do-it-Yourself” Tools

For researchers on a very tight budget, or who have very simple needs might want to consider a DIY approach. All the details can be found in our book, Beyond the Usability Lab: Conducting Large-scale Online User Experience Studies (Morgan Kauffman/Elsevier, 2010). The basic idea is that the researcher will use a little bit of java script and HTML to create a simple web page that introduces the study and launches two separate browser windows: One browser will contain the website being evaluated, and the other browser will contain the survey itself (usually very small, above or below the website browser). The participant will move between each browser as they go through the study. While data are not passed across the two browsers, you can still capture basic data such as task success, completion times, and self-reported metrics.

Qualitative Tools:

Video Tools

Video tools are roughly equivalent to having a lab study on autopilot. They are quick and easy to set up, and are inexpensive. The researcher simply provides a set of tasks and a URL, and identifies the targeted participants. Participants are automatically recruited who fit the profile. The participant is carrying out the tasks, while their behaviors and verbal comments are being captured by a webcam. Once the study is finished, the researcher can view a video of all the sessions and distill some of the high level issues. There is little, if any opportunity to collect any data from these sessions. However, they may work well for the researcher who needs a quick sanity check of a design. The cost is very reasonable, usually less than $20 per participant.

Report Tools

These tools provide researchers with a detailed report from a user session.  Similar to the video tools, the researcher sets up a study by identifying tasks, but they also include a set of open ended questions that the participants answer as they interact with the website. Participants are recruited based on select criteria and participate in the study. The output is a detailed report of each answer by each participant. This is a very easy way to get some high level feedback on a design. While it might take some work to identify the significant usability issues, it is very easy to use the quotes to compliment an in-person study. The cost is also very reasonable, typically less than $20 per participant.

Click and Mouse Tools

Click and mouse tools provide the researcher click and mouse movement data on a website. Unlike the other tools that capture comments (video or written), these tools focus on how users move throughout a website.  There are some very nice visualizations that come out of these tools, such as click maps, attention maps, mouse movements, and scroll maps. These tools are particularly effective at quickly capturing data about what is drawing user’s attention. For example, fivesecondtest.com is very simple in that you can show static images of web pages to participants for five second and participants click on those features that initially grab their attention. Of these tools, ClickTale seems to offer the most functionality, including metrics such as abandonment rates as well as video recordings. The cost for these tools is very reasonable, usually less than $20 per participant or a monthly license for a few hundred dollars or less.

Combination Tools

Combination tools collect a lot of data about the user experience. Some of the data are qualitative such as videos of the sessions and verbatims. Other data are quantitative such as clicks, task success, keystrokes, pages visited, and completion times.  Unlike the self-service tools, these tools are typically used for smaller sample sizes (n<20). They provide a nice solution to the researcher who wants to gain a more complete picture of the user experience with a small number of participants. Pricing is quite affordable, typically a few hundred dollars or less for a single study.

Is your design resistant to failure? If a worst case occurs, can the user recover and regain trust in your solution?

This article explores the case of warnings, alerts and alarms, and provides an introduction to the important factors in gaining user attention to failures or critical events – and how to deal with them. As designers, we all would like to focus on the “happy trail” through our system; but as many users will tell you, annoyances and obstacles to a pleasurable user experience is how a system handles errors and important events out of the ordinary.

Alerts—an interaction design issue

Alerts are used to give the user feedback about important events that need attention for some reason. This may mean errors, failures, breakdowns, or important changes that need action—or interaction. The term “alert” is used here to include different types of significant event feedback in order of criticality:

• Alarms
• Warnings
• Cautions
• Advisory messages

The goal of the alert is to give users the ability to recover from important events. This is basically an interaction design issue.

The goal of the alert is to give users the ability to recover from important events. This is basically an interaction design issue. When we study different cases of system breakdowns, an important commonality occurs. How users respond is often the make-or-break part of the event. Interaction design is a critical factor in empowering the user to do the right thing. Through design, we can facilitate users responding correctly to critical events.

For instance, the Chernobyl nuclear accident in 1982 was characterized by three important flaws in the security system that occurred simultaneously. Functionally, the reactor did not live up to minimum heat resistance requirements. In terms of personnel, the staff lacked sufficient training. But just as importantly, the staff ignored system warnings.

The 1986 Chernobyl reactor accident - a case of ignoring warnings

Ignoring system alerts is an interaction design issue—proving an important point: the interaction design can cause the chain of events to occur—or, through the right design, break that chain and help users recover from failure.

The interaction design can cause the chain of events to occur—or, through the right design, break that chain and help users recover from failure.

Most of us will never work on systems with such a high degree of “criticality.” But we still for need to design alerts as feedback to important events, and regardless of the level of criticality, the alerts will determine users’ ablility to recover. Thoughtful alert design helps that process; it supports the flow of work. This is why alert design matters.

Make users act, not panic

The first rule of alert design is to allow the display to trigger action, correction or recovery—as opposed to causing panic.

Compare it to a trip down the highway in your car. The kids are in the backseat. Suddenly, the engine compartment catches fire and starts to smoke heavily, with flames coming out the side. You brake quickly and pull over. How do you instruct your kids? What voice would you carry? You would probably use a firm voice, right? A raised voice, but controlled. “We need to get out now. Take it easy. Only through the right hand side door. Don’t run. It’s under control.” Your voice should not cause the kids to panic, only to act, and to act in the right way.

The above analogy is actually used when designing cockpit voice alerts. It is also the reason a female voice is often used in most voice alert settings. Users are somehow more prone to respond calmly to a female voice than with that of a male.

Matching criticality to obtrusiveness

When designing the actual feedback element, we can start by looking at visibility. With different levels of importance, how should the obtrusiveness be scaled? This leads us to another important rule in alert design:

Match the obtrusiveness of the alert to the criticality of the event.

Do not make the alert too obtrusive for trivial caution displays. On the other hand, avoid making the design of important alarms too “silent” to be noticed.

Obtrusiveness can be manipulated through specific design elements. Here are some of the major design aspects to manipulate:

• Size and placement determine visibility.
• Colors signal criticality. Need I say more? Use red sparingly, and save it for high criticality alerts and to raise obtrusiveness.
• Static or dynamic. The eye catches movement. Raise obtrusiveness with animation and movement in general.
• Sound/voice. Sound is crucial. If the user is not looking at your display device, the will not notice the alert. This is why most alerts are also audible.
• Repetition: User might not catch the first alert.
• Permanence: Consider the case of missed alerts. User might not have noticed the alert the moment it occurred. By raising the amount of time the alert is displayed, obtrusiveness can be raised.

An example of intelligent alert priority design is the cockpit warning and caution unit. Alert criticality is distinguished by sound, placement, color and size, yet integrated into a single sorted “inbox” concept, displaying all alerts in one location.

Cockpit of an A380.

Dismiss and act—or interact

Depending on which system provides feedback, the user might have options to interact, or just options to “dismiss and act accordingly.” In less critical alerts, provide options for interaction: “Fix”, “Retry”, “Close valve”, “Show list”. This keeps the locus of control with the user and builds trust.

In alert dismissal, there are no particular actions to feed back to the system. In this case, combine the alert with a suggested action: “Engine is on fire. Exit car to the right.”

Cry Wolf Syndrome

The most common pitfall in alert design is to handle obtrusiveness and repetition incorrectly. If the alert is displayed too frequently, the user will become blind to the alert and will then ignore it. It also causes trust to be lowered for other types of alerts. “It does this all the time. I never listen to it anymore.”

The best way to avoid Cry Wolf Syndrome is to make sure alerts are easily dismissable, only occur and repeat when necessary, with the lowest possible interval, and are as obtrusive as their criticality warrants.

Make every alert count.

One design solution to Cry Wolf Syndrome is to create display permanence with less obtrusiveness for the same alert. This can be done automatically “docking” the alert as opposed to repeating it. The user will not be forced to interact with the alert—and possibly dismiss something of importance. Another strategy for avoiding the pitfall is to simply avoid the alert alltogether. Consider if the action or alert is necessary. Can response or interaction be automated—or avoided? This will typically prove to be the best solution to fight user blindness. Make every alert count.

Good design is hard to do. The very nature of human centred design is confronting, challenging and often uncomfortable. Every project builds up a collection of challenges along the way, which can pose significant risk to the project’s success, and if we don’t tackle them head on they can be detrimental for everyone involved. How can  we share and learn from each other’s challenges?

At Neoteny, we refer to the collection of challenges in a project as its ‘challenge pile’, given they’re exactly that; a pile of issues, constraints and problems. We keep track of the challenge piles using walls in our studio for each project. Some are collections of post it notes, others are photographs, drawings, diagrams, scribbles or hand written notes. Each week as part of our work in-progress meeting (team jam), we take stock of each project’s challenge pile.

We ask ourselves the following for every challenge:

• How did this challenge come about?
• Briefly establish the current reality, including:
  • What has it cost the project? Not necessarily in financial terms, what has been the cost to our momentum, resources, client expectations etc.
  • What is the potential impact? In what areas?
  • Could it have been avoided? How or why not?
• How have we handed it thus far? As a group, explore options for how we handle it moving forward.
• Agree on proposed solutions or new approaches and secure buy-in from everyone involved.
• We’ve found that this structure helps us stay out of the drama whilst understanding the drivers for each challenge, and then focus on solutions. This makes the process much more collaborative and productive, we aren’t sitting at our desks sweating over something we could probably work through together in a few minutes.

We recently had a team jam, and here’s what came out of our challenge pile review:

1. Customer needs and business requirements collide.

This project is in its early stages. The client came to us with a new product that they wanted to develop, the first step was to research the product feasibility and desirability in the market.After conducting research aimed at validating the customer need for a new product, we found that what the customer needed and what the client planned to launch, were two very different things.

We’re currently in discussions with the client to try to shift the project objectives and focus, to meet real customer needs. As a group we decided not to proceed to stage two unless we could get their buy in on a revised approach.

Question for readers: What would you do in this situation?

2. Budget streams are unclear for future phases of work.

We’ve been involved in projects in the past that have unclear funding streams for future work. This is especially common in large corporates, where steering committees assign funds based on a comprehensive business case analyses including return on investment predictions. These can’t necessarily be defined without first doing some work. The problem with this structure is that you have a team of stakeholders that can only see as far as the next steering committee meeting. This makes a design project with a strategic foundation i.e.  something that’s designed with the whole in mind, very difficult to manage.

This particular case was flagged early because we’ve seen the warning signs before. The signs included hearing things like:

• “If we build this…”, highlights the fact that the stakeholder doesn’t believe this project will make it to implementation.
• “We need to show results by June…”, if you ask why, you’ll probably hear something like “that’s our next steering committee check point”.
• “We won’t be able to build that”, if you ask why, you’ll probably hear something like “because the next budget release won’t be anywhere near that much”.

In the past, this issue has created a divide between the client or project stakeholder group and the design team. Whilst the stakeholder group is focused on securing the next round of funding to ensure that this phase can move to implementation, the design team is focused on exploring and exposing every possible opportunity for solving the design problem.

We’re currently working with senior management to ensure we have their buy-in throughout this project. In our experience, we’ve found that if the person signing the cheques is on board with the approach, the whole stakeholder group is much more relaxed and inclined to get their hands dirty in design.

Q: Have you experienced this before, and if so, how did you get around it?

3. Stakeholder groups have varying ideas of the project objectives

Have you ever been in a project meeting and realised that the client team doesn’t agree on the project’s objectives? This is an awful moment for a designer. It’s the moment when you move from designer to mediator. Playing mediator with your clients is generally not a lot of fun and not how you want to be spending your energy.

The design team typically work with clients to reach a shared set of project objectives. If you find yourself in a situation where you think this has happened but it isn’t the case, then it needs to be dealt with immediately. This agreement needs to be made before design work can start. Of course, these objectives may shift and be adjusted as part of the design process, but the aim is for adjustments to be made as a whole, not as a fragmented set of perspectives from different stakeholders.

We’re currently experiencing this on a scoping project we’re working on. It came about in a workshop, where up until that point, the team seemed aligned. We handled it by stressing the need for a shared project vision and refusing to move forward without one. We managed to facilitate developing a shared set of objectives, prioritising them and we’re currently working with the client to ensure that every stakeholder is in agreement on the vision for the project.

Without this shared vision, we put the success of the project at risk because no one is clear on what success will look like. We’re currently working through ways to communicate this in a more explicit way to our clients before we start on their projects.

Q: Perhaps it’s about signing off on the project vision, would that make people more accountable?

4. Mystery stakeholder stomps on the project.

Does this scene sound familiar? The design team is working away, the client is happy and excited, they’re getting involved and spending time designing with us. Then BAM! Along comes the mystery stakeholder who has significant influence, but just “doesn’t like blue”. In most cases, the mystery stakeholder is a fairly senior member of the client team who hasn’t been along for the ride and is looking at the design solution without any understanding of the brief, the agreed approach, the challenges or the project’s constraints. This situation can be crippling. Challenges like this can impact resources, motivation, relationships, momentum, time and budget. You could argue that it’s the design team’s fault for not ensuring that all stakeholders were engaged, the project owner’s fault for not engaging the full spectrum of players, or the mystery stakeholder’s fault for stepping in with the ‘I’m gonna leave my mark on this project regardless of how you got here’ kind of attitude.

We’ve started to enforce what we call a stakeholder roll call. At the start of every project, and within our terms and conditions we gather a list of stakeholders, their roles and responsibilities and have the project owner sign off on this list. The full list of stakeholders are required to sign off on all milestones and agreed deliverables.

We acknowledge that the stakeholders may change, but the terms allow for this situation and protect the progress we would have made in the project up to that point. The success of this approach remains to be seen, though what it does achieve is a level of accountability agreed up front for the potential impact of those ‘stomping moments’.

Q: How do you protect your projects from random stakeholder stomping? How have you dealt with this situation in the past?

Where To From Here?

As you’d expect, there’s a ‘magical box’ of learnings and insights created by each challenge pile. It’s what we choose to do with the magic that makes the obstacles and the heartache worthwhile. I’m sure we’ll learn a hell of a lot more as our company matures, but here are some of the more salient ones we’d like to share with you:

• There’s not always something ‘to do’, there’s something ‘to know’. There are situations we can’t ‘solve’ in the context of the project we’re working on. But being aware of the specific challenges and carefully managing expectations accordingly can be a very effective approach, one which better supports our potential success.
• As a company (and perhaps as an industry) let’s be more reflective. That doesn’t mean we have to wade into the drama or analyse it ad nauseam, but we do need to nip things in the bud, be honest with ourselves and the team, be open about the potential impact that the shifts might have, and involve everyone.
• Getting the players involved as the challenges arise. Rather than keeping our ‘dark passengers’ under our hat, and suffering in relative silence, all with a smile on our face, let’s face the challenges together! Clients and project stakeholders are often quite pleased when you invite them to be part of the solution. Any shifts to the project approach are also much more likely to fly if we’ve got buy-in from everyone involved.
• Sharing the good the bad and the ugly with our peers. Let’s foster a culture where we share both our triumphs and our failures, rather than keeping the latter closely guarded. As a collective mind, I’m sure we can come up with some inspired, insightful ways to circumvent and also completely avoid some of these challenges.

We believe that we can get better at this thing called ‘design’ if, as an industry, we can make the most of lessons we learn from these challenges. After all, they enable us to be more resourceful, they give us an opportunity to be more creative, to build stronger teams and deeper relationships.

So, what do you think?

Michelle is one of the speakers at UX Australia 2010, taking place 25-27 August 2010 in Melbourne, Australia. The conference has sold out, but workshops are still available, or you can go on the waiting list. See the UX Australia site for details.

This is part 2 of a two-part post. Read part 1.
In the last installment, we talked about the distinction between Hands contractors and Brains consultants. Hands are brought in by the team as an extra resource to complete work the team already knows how to do. Brains are brought in by the team to provide expertise and insight on the best way to do something the team is struggling with.

Hands and Brains require completely different skills, have different approaches, and run into different challenges. Knowing which you want to be is important.

The role of Hands

The UX professionals who make great Hands are passionate about producing stuff. Whether it’s a pile of wireframes or a boatload of usability test sessions, they can crank through them. More importantly, they tackle every single piece of the project joyfully and proudly.

The thing to remember is someone who signs up to be Hands typically doesn’t get to say how the project is done. The team decides that up front, often before the project is started. It’s up to the Hands to match the work exactly, making it impossible to know which elements came from the Hands and which came from other team members.

When it comes to how the work is done, creativity and previous experience aren’t playing big roles. In fact, they are frowned upon. While the team focuses on getting everything done by the end project, they don’t want to step back and take the time to rethink what they are doing.

The Hands will get management’s attention if they have tricks and techniques for speeding up production, while keeping the results indistinguishable from what’s been done so far. An experienced Hands contractor brings speed and agility, while playing the chameleon to match the work of their temporary teammates.

Bring in the Brains

This is a complete opposite to the Brains—who aren’t about production at all, but instead about strategy. The Brains, when at the top of their game, are the sheriffs, coming in to clean up the town. When a team is stuck and not making progress, and it feels like they’ve tried everything without results, they call in the Brains.

Unlike the Hands, the Brains doesn’t make a good producer. Their value is squandered if they spend the bulk of their project time churning out similar items. Of course, if the team is struggling with what to produce and how, the Brains can get them started, showing them the technique and coaching them through the work. But, in this scenario, the Brains quickly backs away, as soon as it’s clear the team members can produce their own results. (Some Brains will bring Hands into the project at this point, working jointly.)

Instead, the Brains’ real value is in strategic understanding of the situation. The Brains looks at the entire scope of the project, studies the goals, and assesses the team’s capabilities and flaws.

Then the Brains suggests a new plan. They get the team started on the plan. They train the team on the tricks and techniques that will get them through that plan. Then they leave town, just like the sheriff, to go off and clean up the next team’s mess.

Why The Difference Matters

Great Hands know how to produce. Great Brains know how to analyze and persuade. They are completely different sets of skills. Hands and Brains require different personalities. It’s very rare to find one person who does both.

Great Hands know how to produce. Great Brains know how to analyze and persuade. They are completely different sets of skills. Hands and Brains require different personalities. It’s very rare to find one person who does both.

The Brains aren’t challenged by production work. Once they’ve done one screen or conducted one test session, they’re ready to move on to something completely different. The Brains love the variety of the tasks—coming in to something new. The Brains love seeing problems and solutions nobody else seems to see. The Brains are energized when those problems are particularly gnarly and the solutions are deviously elegant.

The Hands struggle with strategy. They always feel they’re the wrong people to ask—that someone else should’ve figured this all out by now. They thrive on having a set of constraints, a schedule, and a near impossible pile of similar things to do. They love to crank through the work, seeing the Done Pile grow while watching the To Do Pile shrink. They don’t mind their work blending with the rest of the team’s—their contribution becoming invisible to anyone outside the team. They are energized by completion.

In other words, Hands thrive on walking into a project that’s well defined while the Brains thrive on walking into a project that’s poorly understood. That’s why it’s difficult to be both. It’s a very rare person who thrives on both definition and chaos. For everyone else, they need to choose one or the other.

I’ve seen managers who have tried to have one individual contributor play both the Hands and the Brains. Often this is because of resource constraints or not realizing there’s a difference. Unfortunately, this inevitably ends in disaster, because of the opposing strengths and weaknesses of Hands and Brains. Don’t fall into this trap.

What do you thrive on? What energizes you? Where do you get frustrated? Understanding this will help you figure out if you are suited for the Hands or if you ought to be the Brains.

Jared Spool is the keynote speaker at UX Australia 2010,  being held in Melbourne from the 25-27 August 2010. The conference has sold out, but Jared’s workshop and others are still available, or you can go on the waiting list. See  the site for details.

What’s the difference between contracting and consulting? One major difference comes down to whether the job is handwork or brainwork. Whether you’re an “innie” or an “outie,” this is applicable.

Innies are UX professionals who work inside an organization. Even though they are part of the company, they are still consultants. They are brought on to projects with the intent of lending their skills to move the project forward. Sometimes they stay with one project for its duration, or sometimes they juggle multiple projects at once. Either way, they aren’t really part of the long-term team in the same way others are—they move from team to team and are only there when their skills are in demand.

Handwork and Brainwork

Innies and outies have a lot in common. One thing they share is the need to distinguish whether a project is handwork or brainwork.

Handwork is when the hiring team knows what they want; they just lack the right number of hands to get it all done. Let’s say the team needs new screens designed. They know what the screens are and how they should work. They’ve built many screens before, quite successfully, so it’s not a problem of knowing what to do.

The problem is they don’t have enough hands to get the job done. All of their internal resources are otherwise occupied, thereby stalling the screen-production piece of the project. In this case, they hire a contractor—someone who will come in and help them crank out more screens. This is handwork.

But there’s another way the project could go down. What if our hypothetical team doesn’t know what the screens are or how they should work? What if they don’t have the experience of building screens before and lack the confidence and skills to get started efficiently?

In this case, they need someone to help them come up with a strategy for identifying which screens need work and how to tackle them. In fact, once that strategy is set and they understand what the project needs to be finished, they may have, internal to the team, all the resources necessary to complete it.

This is when they hire an outside consultant; someone who will bring in expertise and skills the team doesn’t otherwise have. This we call brainwork.

Hiring Hands and Brains

It’s quite critical, as a UX consultant (whether you’re an innie or outie), to distinguish between handwork and brainwork—yet the distinction is often not discussed. As I talk to people who are looking to expand their careers, what I discover is they are often trapped doing handwork when what they really want to do is brainwork. (Occasionally, I meet someone who prefers to do handwork to brainwork, but that is quite rare.)

Handwork, for the most part, is commodity work. Once you qualify the basic skills, it really doesn’t matter who does it. It doesn’t take imagination. Previous experience, for the most part, doesn’t play a role in the quality of the output.

If the team needs to produce 100 wireframes and they have a pool of 20 people who are capable of producing those wireframe to their specifications, then it doesn’t matter which of those people you hire. Hire the one who charges the lowest rate, has the nicest personality, and produces the cleanest deliverables.

Brainwork, on the other hand, is where your expertise and experience come into play. If the team doesn’t know what a wireframe is or how to decide what they should do, they’ll want someone who can give them solid advice. It they’re smart, they’ll be selective about who they hire, looking for someone with a track record of helping other teams in comparable situations, and they’ll pay top dollar for their help.

Maybe the team’s leadership is mistaken and they shouldn’t be doing wireframes at all? Well, someone hired to do brain work will have earned the respect and authority to say, “You know, there’s a better way to do this” and the team will listen. (Occasionally, they’ll even revise their plans, but that’s another column for another day.)

However, if that same person was hired to do handwork, there’s no way the leadership will pay attention. It’s wasted breath (or worse, seen as belligerence that may result in removal from the project). Handwork is hired for hands, not brains. Please keep your brains to yourself.

UX professionals who do handwork are what we call the Hands. They’re a rare and valuable breed. Find someone who loves being the Hands and you have a production machine.

The Brains are what we call folks who provide great brainwork. Prospective employers have to be more discriminating when hiring the Brains, because their advice will drive the results, either to success or to failure.

Hiring managers should know which they want. Get the right person for the job and you’ll have a successful project. You need to distinguish between Hands contractors and Brains consultants. In the next installment, I’ll talk about the qualities that separate a great Hands contractor from a great Brains consultant.

More thoughts on this topic: Should You Be Hands or Brains?

Want to meet Jared?

Jared Spool is the keynote speaker at UX Australia 2010, being held in Melbourne  from the 25-27 August 2010. To pick up one of the (less than 30 at time of going to print) tickets, register on their site.