ia play

The classic usability complaint is that projects just tack a usability test on at the end of development when it is too late to make any changes. Which leaves the usability consultant in the uneviable position of having to tell the project team that their product doesn’t work, when they can’t do anything about it.  It can feel like a waste of time and money.

In reality these sessions are rarely entirely useless and I’d prefer to run them rather than having nothing at all. A lot of feedback is often about content which can usually be changed at the last minute.  You can also capture general customer research insights that can feed into the next project.

A couple of projects I’ve got involved with recently have involved late stage usability testing . We need to tackle this but we’ve got some bigger challenges than usual in bringing in a better approach to usability testing.

1. The organisation can’t afford rounds of testing

This is hardly unique to us and I fully expected this when I took the job. The answer usually involves the word “guerrilla” at some point.

2. We have some challenges in doing guerrilla testing

Our target audience (blind and partially sighted people)  is a small section of the population and can’t easily be found by popping into libraries and coffee shops. Everybody else really isn’t representative and would give completely different results. Although admittedly our target audience can often be found in our own offices, or rather in the public resource centre downstairs. But you can’t just get them to test on your laptop as you need to have the access tech that they are used to using. We might need to try and find folks who are both willing to test and also use the access tech we have available. Not insurmountable problems, but will take a bit of planning.

3. Can’t easily do paper-based testing or flat onscreen mock-ups.

I’ve mentioned this particular challenge before. We can survey and interview quite easily. We can test existing or competitor systems. But when it comes to trying out how well new designs are working, our options get a lot fewer. Whilst it would be interesting to experiment with tactile mock-ups, the admin overheads and learning curve probably aren’t justified.  Really we should just concentrate on working prototypes, rather than getting carried away with how cool an IA presentation idea “tactile wireframes” is.

A recent conversation with a friend generated shock (and even a little scorn) that I’d been producing wireframes. I was firmly entreated to sketch instead. Around the same time a recruiter approached me with information on a job that would require detailed annotated UI specs of around 40 pages every fortnight.

The profession is still judged, by and large, by the quality of our documentation. Most recruiters and hiring managers seem more interested in the quality of annotation than the quality of thinking.

I’m rather inconsistent in my approach to documentation. Mostly the medium is picked for the context. Is the project agile? How good are the developers? Is there a remote team? Do lots of people need to be consulted? What are their reading preferences?

Whilst I’m happier with pen and paper  than computer, I think it is far to say that I doodle a good deal more than I sketch.  Now there’s always a way to get chickens into a blog post… this little trio were sketched during a conference presentation, presumably a scintilating one and probably about something 2.0 related given the labelling of the fowl.

In fact, it appears I doodle most when irritated by the speaker. In this case , rather than asking an insightful question to highlight the cliched and superficial nature of the argument, I wrote “blog, wisdom of the crowds, whatever”. That told him, I’m sure. I do still want this mug though:

None of this is what my friend had in mind though. She’d like this more: part user journeys, part concept map, but mostly not very pretty. Not really for sharing (apart from with you lot, of course) but it could be re-jigged into something more respectable.

I do these little pages all the time but again they aren’t for collaborative purposes. This one was so I could sanity check we had all the functionality we’d need on the product backlog before the supplier drew up the drawbridge.

Then of course, there’s cheating. Those search forms I shared recently were created in Visio but with the sketchy stencil:

I very rarely do this kind of documentation anymore. My business stakeholders are bored by them and the developers are best told what to do by pointing over their shoulders.

I do still do content models. This kind of specification still gets traction with the developers:

But, horror of horrors, a lot of my documentation these days is actually reasonably high-fidelity mock-ups. These are really aimed at the business stakeholders. Colours and fonts are pretty much fixed by our visibility requirements, so the business units know better than to ask for their favourite shade of puce.  And they worry less if they don’t have to try and visualise from wireframes. It doesn’t take me any longer as I’ve got a colour stencil and the choices are pretty limited.

Is this ironic? I’m working for an organisation of and for blind people and I’m producing the most colourful deliverables ever.  But then you should see the colour of the office floors.

In the old days job titles were created by grabbing a bit of Latin/Greek and adding ‘er’ or ‘or’ to it. The suffix just means “one who does”.

Something of the bits of Latin /Greek are obvious, some not:

Carpenter=wagons, Cooper=vats, Plumber=lead, Lawyer=law, Miner=digging, Baker=roasting, Butcher=slaughtering goats, Doctor=teaching, Teacher=also teaching, Farmer=collecting tax/rent, Soldier=being paid, Tinker=jingles, Tailor=cuts, Dyer= dark/secrets

Vicar interestingly just means substitute or deputy.

And who slaughtered anything that wasn’t a goat? (I’m putting the etymological dictionary away now).

It seems for a modern job title that a single word is not enough. You need a combination of object and activity.

Possible objects in my professional sphere:

project/programme
product
business
content
user experience
customer experience
usability
interaction
systems
software
applications
development
technical
information
accessibility
search
web
digital
online
intranet
e-commerce
sharepoint

Posssible activities:

manager
analyst
architect
designer
producer
engineer

Some people seem to feel hemmed in by the activities bit and choose something vaguer. This usually implies they will only produce opinions not things e.g.

consultant
expert
specialist
professional

In the public and non-profit sector you also get ‘officer’ as in police officer but also projects officer or knowledge officer. This usually just means one who holds an office and seems to be a way of avoiding saying ‘man’. “Head of” is similar but usually at the opposite end of the hierarchy.

All combinations of object and activity are plausible and many are common. Although so far I only know one Usability and experience design oompa-loompa.

NTEN continue to share lots of useful information about their redesign process, including this insight into their web analytics:

“Our bounce rate is pretty darn high for folks who find our site through search: about 68%. New visitors also bounce at a high rate: about 67%. Our blog, which gives us the most traffic from search, has a bounce rate above 75%.

Friend of NTEN Avinash Kaushik says that organizations should aim for a bounce rate under 50%. We don’t expect our new visitor bounce rate will get THAT low, but there’s some work we can do to make sure people find MORE great content and stick around our site.”

via Wireframe Testing: Failing Informatively | NTEN: The Nonprofit Technology Network.

I’m probably going to get a new job title. And it won’t be UX-anything, so don’t worry that I’ve had a change of heart on that.

I don’t use my IA title much within the organisation. The web team get it but that’s four people.  I tend to introduce myself by what projects I’m working on. In project kick off meetings and meetings with stakeholders I’ll explain what I’ll be doing on the project but not my title.

A lot of the teams I work with are intimidated by IT projects. And for them the language of user experience design and information architecture is as alienating and terrifying as the language of server architecture and database design. It is all big words from people who get paid more than they do and seem to work in an alternate universe of conferences, social networks and blogging.

So mostly my introductions go something like…”I’m Karen, I’m part of the project team and I’ll be responsible for making sure users can find their way around the new site”. Or “the search actually works this time”. Or “putting your content into the system isn’t such a nightmare”.

So my boss and I are trying to come up with something that both more accurately conveys what I actually do and is also a user friendly one.

Anyone got any examples of doing user research into what their job title should be?

“Admit it. Ours can be an insular profession. As much as most of us think we communicate simply and effectively, we often don’t. Why? I think it’s because we’re sometimes overly concerned about how we’re coming across to our fellow UXers. You know what? Forget about them. Your real audience is the business stakeholder. When you’re planning a presentation or trying to figure out how to communicate your research or design solution, don’t let your inner Nielsen—or head-Nielsen for fans of the reimagined Battlestar Galactica TV series—prevent you from communicating in terms and concepts that your stakeholders can understand and groove on.

You know what this means, don’t you? You’re not allowed to use the term heuristic evaluation anymore. Banish it from your professional vocabulary! Now, wave goodbye to it, because, if you use it again, I will personally come to your house and punch you in the arm.”

via 8 Things You Should Be Doing in Your UX Practice, but Probably Aren’t :: UXmatters.

Absolutely. Couldn’t agree more. But it is ok to tell them you are user experience designer?

The Nonprofit Technology Network have been sharing lots of info about their ongoing site redesign:

We’re going to make sure our site architecture is sound before we worry about making it purty.

The story so far:

* We started with a card sort. Rebecca Sherrill, our Information Architect at Beaconfire, has written a terrific synopsis of that process, with definitions, a walk-through of the process, and an overview of the findings. You should read it.

* Building on the results of the card sort and an Audience Matrix (Excel) we had filled out earlier, Beaconfire produced a draft site map. Holly and I worked with them in a conference call to revise the map (PDF), then brought the entire staff into the process during our weekly staff call.

Beaconfire now has our feedback, which they’ll use to refine the site map, then produce a wireframe version of the site.

via Redesigning NTEN.org: of Card Sorts and Site Maps | NTEN: The Nonprofit Technology Network.

IDEO have created a free downloadable toolkit for NGOs and Social Enterprises.

The Toolkit is divided into four sections:

The Introduction will give an overview of HCD and help you understand how it might be used alongside other methods.

The Hear guide will help your design team prepare for fieldwork and understand how to collect stories that will serve as insight and inspiration. Designing meaningful and innovative solutions that serve your customers begins with gaining deep empathy for their needs, hopes and aspirations for the future. The Hear booklet will equip the team with methodologies and tips for engaging people in their own contexts to delve beneath the surface.

The Field Guide and Aspirations cards are a complement to the Hear guide; these are the tools your team will take with them in order to conduct research.

The Create guide will help your team work together in a workshop format to translate what you heard from people into frameworks, opportunities, solutions, and prototypes. During this phase, you will move from concrete to more abstract thinking in identifying themes and opportunities and back to the concrete with solutions and prototypes.

The Deliver guide will help catapult the top ideas you have created toward implementation. The realization of solution includes rapid revenue and cost modeling, capability assessment, and implementation panning. The activities offered in this phase are meant to complement your organization’s existing implementation processes and may prompt adaptations to the way solutions are typically rolled out.

via Human-Centered Design Toolkit – Case Studies – IDEO.

This article is part of a series about our e-commerce redesign.

I had some quiet time over Xmas and did some current state analysis of the online shop then. I’m so glad I did this. As per usual, as soon as the project actually kicks off there is limited time to do this sort of thorough research.

One of our business analysts has done a formal “as-is” review of the back-end processes but I’ve been concentrating on the front end user experience, particularly browsing the catalogues.

For my current state analysis I identified all the existing features. To do this:

• took lots of screenshots, of all the screen variations I found
• made a sitemap
• annotated the documents, identifying each separate element

Now just because we have all these features now, it doesn’t mean we want to keep them. That said, during the website redesign we missed things that are working really well on the existing site. The site looks clunky and old-fashioned but there’s some nice features in there. So I wanted to make sure I genuinely knew the site inside out.

The functionality basically breaks down into:

• arriving on site (including via search engines)
• finding and choosing items
• information about purchasing
• registering
• adding to basket and purchasing
• tracking/cancelling

I’m going to concentrate on the first two areas for now.

Within the main shop (i.e. not the book shop) there are

• a store homepage
• category pages (including sub-categories)
• product pages

There’s also a sitemap, terms and conditions, product news, pricing information, contact forms, and help information but the other three are the main page types.

The project already has a product backlog from an earlier attempt to kick it off. After I have annotated all my screenshots, I compiled a list of features and then compared that to the product backlog.

The backlog was missing the following elements:

• link from product page to product instructions
• link from product page to other product guide/pages
• link from category page to product category guide e.g. choosing a mobile phone
• information about product size
• offer product variations e.g. colour and size
• product image
• product image enlargement
• seasonal offers and selections e.g. Xmas
• alternative ordering information e.g. call this number
• vat price + non-vat price
• login as different types of shopper
• links to t&cs
• communicate different delivery prices (free, special + xmas)

This flagged up for me a problem with the way the backlogs were generated. Stakeholders contributed ideas for features they wanted to see but tended to assume they would automatically get all the functionality they already have. Even with this process, I almost missed out search from the list, as it is part of the main website navigation and I was ignoring the standard page “furniture”.

Some of these gaps would indeed be obvious as we built the site but a number are not standard e-commerce functionality and it is entirely possible that the project team wouldn’t have thought of them independently. So for me the current state analysis catches functionality that might otherwise have slipped through the net.

Next: business requirements

One of the blogs I follow faithfully is The Simple Dollar. In  The Variables of a Purchase: Is Price the Ultimate Bottom Line? Trent says

I place a significant extra value on buying local produce and dairy products versus buying items that are shipped in. I place a slight premium on the ethics of the business, but I often find that companies with questionable practices often have many competitors and it’s trivial to simply use more ethical businesses. I have something of a minimal standard for customer service and shopping experience – if a company doesn’t meet that standard, I just don’t give them my business, regardless of price, but above that level, I view all competitors roughly equally.

So  Trent has a ‘minimal standard’ for shopping experience but there are other factors that he places higher value on.

I came back to this thought when reading yet another perplexed UX blogger, wondering why the field isn’t sufficiently respected or valued.  As usual, I thought of iPlayer.

The user experience team that worked on iPlayer had many anxieties about the product that launched.  The UCD process hadn’t been followed as faithfully as it could have been. Everyone felt the UX could be better (although we didn’t necessarily agree about what was wrong).

And yet, iPlayer has been a massive success for the BBC. And appears to have turned the guy in charge into The Man Who Saved the BBC and gave him the opportunity to say in print “I only do things for the user”. Those users were delighted to get their favourite shows for free,  so appear to have put up with the clunky bits of the UX.

(Now Five On Demand. That’s a different matter. The UX sucked, I was only mildly interested in the product and they were expecting me to pay. No thank you.)

With free services, I definitely put up with some rather undesirable user experiences. Google apps are a mess when used on my EEE and the keyboard shortcuts are patchy but I stay faithful. I use Swapshop all the time and that’s a shocker.

But is it different when I’m paying?

I like the user experience of Waitrose way more than Morrisons. But I go to Morrisons. Mostly because it is near my house and a bit because they stock the things I buy regularly.

We also buy meat direct from farmers and I can assure that the user experience of that process is absolutely awful. But we persist. We like the pigs.

When travelling I buy the cheapest, direct flight and then complain about the customer experience when I get home. I can’t stand American Airlines but when my parents lived in North Carolina I flew with them many times a year. I still get mad when I talk about their flight attendants but they were the only airline that flew direct from London.

Some services I do care about how good the UX is.  Others it isn’t the deciding factor.

It isn’t enough for UXers to say “UX matters”. Because sometimes it doesn’t matter enough to stop someone making money. You have to have a developer otherwise you won’t have a site. But it is possible to launch a successful website without a UX designer and even without a particularly good UX.

Not always, but sometimes.

So when does UX matter? And how do you know if this is one of those times?