Sentiment sketches for customer discovery

No, this was another problem, one that would come to colour much of the design work that informed the project.

The client had diligently done a Discovery phase, and this left them with a wealth of information. Chief among this was a comprehensive list of users. This was a spreadsheet 100 rows long! They had identified 100 different user types, each of whose needs had to be addressed. Even the most ambitious analysis couldn’t reduce this data to fewer than ten groups.

It was clear that generating 100 personas and the umpteen user journeys that they would each take in their interaction with the organisation would not help anyone make any decisions about the project. It would always be possible to find a counter-argument amongst all this data. Decision paralysis loomed.

What I did was divide the users into a few broad groups, then I drew what Chris Spalton, Product Designer at Redgate Software, refers to as Sentiment Sketches.

Chris advocates sketching the sentiment of a design once you have the basic idea of it. This allows you to get a sense of how it should feel when the user completes their journey, without getting bogged down in the details of which screen comes in what order.

As this was before we had formed a cohesive vision for the design of the project, I was not ready to sketch the sentiment at that level.

Instead, what I did was to sketch the ideal sentiment for users coming into contact with the organisation, in any one of a few dozen ways that had been outlined in their Discovery.

Creating the sentiment sketches

Each sketch includes:

• A depiction of the problem that drives the user to interact with the organisation in the first place (on the left)
• A hint at how that problem gets addressed by the interaction (in the middle)
• A depiction of how the user might feel once the transaction has been successfully completed (on the right)

So far, so good. I colour coded them for internal and external audiences, scanned them in, and there you go.

The 41 sentiment sketches

Using the sentiment sketches

But what was I going to do with them?!

The answer was deceptively simple.

The university had so many user types because it is a genuinely large organisation with its five thousand staff members (with a tense split between those who are involved with teaching students and those who ensure that that teaching can happen), and tens of thousands of students from all over the world, researchers, not to mention the external funding bodies, government agencies and, yes, local residents.

Over the course of the project, we would need to liaise with many of these to negotiate what was required for their new website and portal.

Part of the problem with their existing offering was the convoluted, organisation-focused language and structure. This is a very common symptom for organisations of this size, and stems from numerous contributing factors. A significant factor being the fact that the digital assets of the university were the product of unplanned growth. Separate departments with overlapping or conflicting messages, produced content which was uploaded to the website without checks and balances over what should and shouldn’t go ups there. There were other factors as well, but I won’t go into them here. Suffice it to say that the university was very typical of organisations of this size and maturity, with all the common ailments of legacy infrastructure, internal attitudes towards the web, and the rest.

The difficulty for a User Experience designer

The difficulty for a user experience designer with organisations like this, is that you need to work with the client to ensure a customer-focused experience, but the client may be entrenched, through no fault of their own, in a jargon-infested labyrinth of internal procedures and doctrine.

If I asked each separate department ‘so, what needs to go on your bit of the website?’ The answer that I would have inevitably received would have been ‘exactly what’s there, thank you’.

But the stuff that was there was what was making it difficult to use and manage!

Couple that with changes we were proposing about how the project would be constructed, which were radical and technical, and you had a recipe for large parts of the organisation going ‘Huh?’ And, simply not engaging with the project. This would have been a catastrophe.

So, in steps the sentiment sketches. These sketches accompanied me on a whirlwind tour of the university. I met almost every department in small groups and conducted some exercises, often in under an hour, to discern what their most potent user needs were.

It didn’t always work, but by heck, it DID work!

People’s eyes opened, they smiled, they thought about the users. They, on the whole, got it.

We had people persuading their teams against using organisational jargon, and moving towards more user-centric classifications of information - a total win for the user. Users became part of our participants’ vocabulary.

It wasn’t uncommon for people to start a session espousing one heavily entrenched perspective: ‘let’s just keep what we’ve got’. By the end of the sessions, in the best cases, we had people reoriating to ‘but would that work for the user?’ or ‘I don’t think that would work for our users’.

A typical workshop panned out:

Present the current state of the project

• There were significant changes affecting the sites
• We used a slide deck to run people through it
• Later, an html prototype I had coded, with visual designs by a third party.

Invite stakeholders to view the sketches

• Bit of an introduction to the sketches
• Participants pair up and pick out any relevant ones
• These go on the wall

Stakeholders write user needs on post-its while considering the sentiment sketches

• These also go on the wall
• Facilitate grouping of needs
• All the post-its are grouped under headings

After that, I go away to document and distribute all of this.

Sentiment sketch outcomes

This process gave me a large library of actionable user needs that I could ensure were catered for by every design on the table, and by every user story going into the backlog.

It gave the project team a higher degree of confidence that the project was not only going to address all the needs of their users, but also of their internal stakeholders. This leads to buy-in across the board and a much higher chance of the project reaching a satisfactory conclusion.

Not only that, once I had documented all the design requirements, I was able to go through all the sentiment sketches again, to check that each problem represented by the sketches had indeed been addressed by the solution.

Bottom line: sentiment sketches encourage your clients to empathise with their users! They're easier to read and more cost-effective than personas (when there are lots of them)! What's more, they're more engaging than user journey maps (but not as detailed)!