Article
0 comment

Creativity activity: letterscouting


Here’s a simple, fun and effective activity to try if you’re after a quick way to stimulate creativity: letterscouting. You can try this by yourself or in a team, and the results can be really surprising.

All you need is a camera phone. OK, you could use any type of camera, but there’s something about the quick convenience of a camera phone that lends itself to this sort of activity. The point of this activity is not to produce perfect photos but to stimulate creative observation of the world around us and looking/thinking at/of familiar things in new ways.

Here’s what to do:

  1. Set yourself – or your team – a time limit. 5 minutes is plenty.
  2. Roam around and take a photo of something that looks like each letter of your name. So if your name is Ben (like mine), you should end up with 3 photos – one that looks like a B, one that looks like an E, and one an N. Of course you can take photos of letters in signage, graffiti, and so on, but you get extra points (read creative satisfaction) if you can find letters in real-world objects and their placement.
  3. Come back together again and share the results.

You might want to then compile them and put them somewhere to share. They look really cool put together as your name, and even cooler as a group of names. And unless you happen to have a really long name, you may need more than 5 minutes… but the idea is to not look for the perfect photo, just anything that looks reasonably like letters.

I did this activity with my team at Digital Eskimo, at the end of our team meeting, and it was pretty fun. Here’s mine:

A set of photos of real-world objects that go together to make my name, Ben

… and here’s a couple more:

Photos of real-world objects that string together to look like the name STEPHEN

Photos of real-world objects that string together to look like the name YVONNE

So try it! Who knows, maybe we should start a Tumblr blog or Pinterest board for this sort of thing. If you know of one, or want to start one, please let me know.

Article
1 comment

Best client feedback ever

Client feedbackThis type of client feedback doesn’t come along very often!

Yesterday myself and a fellow Eskimo were conducting a concept testing session with various stakeholders on-site with a client. By concept testing, I mean running a set of activities geared to taking in structured, measurable feedback about interface sketches and other concepts that we’ve been working on.

All the stakeholders take to our sketches with green dots (for what is useful, and supports their jobs and expectations) and red dots (for what doesn’t). Further feedback and ideas are captured on post-its, for further discussion. This means that more accurate feedback is captured, and everyone gets a proper say.

We’re used to getting a range of feedback, but this post-it (above) is probably the best ever!

Working together on a business model canvas for a 'micro-help' exchange service
Article
1 comment

Breakthrough thinking at a service design workshop

Working together on a business model canvas for a 'micro-help' exchange service

This week has been a week of breakthrough thinking, thanks to a fantastic service design workshop I attended. Not only breakthrough thinking for me, but learning more about bringing out breakthrough thinking in others.

So I went to a 3-day service design workshop, conducted by the venerable Mr Marc Stickdorn (he kind of knows a lot about this stuff) and hosted at the University of NSW (thanks Selena!). I could go on a lot about some of the awesome people I met, or the specific techniques, but instead I wanted to focus on the thinking shift it showed me. I thought it was a short course about the process and techniques of service design, i.e. designing the whole experience around interacting with a particular product and/or service, rather than just a product.

It (happily) turned out to be much more. It was very much a train-the-trainer approach, for us designers to equip clients to do these processes and techniques for themselves.

This has two big impacts on what I do for a living:

Workshops are the end, not just the means

I’m very familiar with conducting workshops with clients, using a variety of fun collaborative activities to draw out ideas and insights. Everyone comes away feeling enriched and empowered, but I then have to process all those ideas and insights into a user experience strategy, and then design whatever it is that needs designing.

Filling out a stakeholder value map

Filling out a stakeholder value map

But the difference with service design workshops is that they’re not just a means to an end (i.e. the strategy and design); they are the end. The strategy and design are captured in the workshops themselves, and embodied as prototypes. Clients are not just buying a designer’s time and skill to come up with something; they’re buying the workshops to come up with something.

This is exciting. It’s also confronting for any designer who favours the smoke-and-mirrors-then-big-reveal approach. I embrace collaboration, I really do, but this has shown me that there’s more I can achieve with those moments of enrichment and empowerment that clients experience within the workshops.

Workshop activities are to iterate, not innovate

Another professional habit I’m in is to conduct research workshops to draw out the business intelligence, ideas and insights from a client, and then conduct concept-testing workshops to test the designs I’ve come up with. And these two types of workshops have different types of activities.

But what Marc has shown me is that these service design activities and techniques are to iterate, not innovate. Rather than doing them once, they can be done over and over again, to model different ideas, and refine service prototypes.

Working on a storyboard of a 'micro-help' exchange service

Working on a storyboard of a 'micro-help' exchange service

Rather than just using the Business Model Canvas to draw out a client’s business model, for example, we can use it over and over again to draw out, model and refine different concepts. What would happen if Energy Australia viewed their customers as co-generators of their product? What impact would that have on the experience of getting and paying bills?

Or what would happen if your petrol was cheaper if you loaned your car for short stints to others when you weren’t using it?

Do more, talk less

End game? For me it points to project relationships with clients where we all do more, and talk less. Clients get to do more, and we all know the positive benefits of learning by doing. They get to experience breakthrough thinking in ways they can’t do through conventional means. For me it means I get to take them there, and equip them to keep taking themselves there. It also means less report writing and more time with clients iterating on solutions.

Sounds like fun, doesn’t it?

Special mention

As well as ups to Marc Stickdorn, I can’t go past mentioning — and profusely thanking — Markus Edgar Hormeß and Adam StJohn Lawrence for their time over Skype answering our questions and sharing some great insights and experience. When I grow up I want to be them!

Article
2 comments

Making personas more useful with persona profile tables

The user experience camp seems a bit divided about using personas as part of user experience design. There are a couple of charges laid at personas’ feet that I think can be lifted by using profile tables together with the personas themselves.

When I talk about personas, I mean the archetypal constructs of characteristics, drivers, behaviours and goals that are designed to represent the main audiences at which a digital product is aimed. Personas were made popular by Alan Cooper, and given gravitas and discipline by industry minds such as Andrew Hinton and Jared Spool.

Pros and cons of personas

It’s true that personas are very useful for informing and validating user experience design. Here are my favourite advantages and benefits:

  • They’re a convenient combination of sensible scenarios and user requirements that are more understandable and accessible to people not familiar with (or prepared to read) copious volumes of technical documentation
  • Everyone – designers, project managers, project stakeholders and developers alike – can relate to personas (and if they don’t then the personas probably aren’t authentic enough), so they can act as a great unifier in project vision
  • They keep everyone honest and the design true to its purpose; by referring constantly to the personas, design and development is kept focused on what’s important for the target audiences and their tasks and situations
  • They are great argument enders; personas can often become the true arbitrator of discussions and debates about whether this feature should be included or not, or whether that phrase is the right tone or not

But personas are not without their criticisms. Some of the charges laid at their feet include:

  • They’re too abstract to be of useJason Fried describes them as artificial, abstract and fictitious, so they can’t provide authentic responses to designs, and be biased and unpredictable, just like real people
  • They’re just another part of the paperwork – many people across the project and client-side get documentation fatigue, and are not likely to absorb and learn from the personas
  • They can be seen as a bit of a luxury at best and time-waster at worst, where many people would rather just get on with designing and building

Persona profile tables: measuring significance of requirements against personas

Where personas can be a shorthand version of user requirements, profile tables provide a shorthand version of how significant the business- and functional requirements are to those personas. Profile tables have a list of features, functions and other contextually relevant aspects in the first column, then one column per persona displaying a measure of significance to each persona for each feature/function.

The‘significance’ bit will depend on your project, and profile charts are most effective when you are specific about the nature of this significance; it’s subtle but important. For example, it could be:

  • How likely it is that each persona would use that feature
  • How important that feature is to each persona
  • How often that persona would use that feature

The ‘measure’ bit shouldn’t be binary – like a tick or cross – because personas (just like us) are rarely black and white about these things. Use other measures that include ideally five points along a spectrum, such as:

  • Harvey ball notation – an array of circular ideograms, filled in by portions to indicate amount:
  • Set of Harvey Ball notation images with their corresponding amounts
    Harvey ball notation - none

    None

    Harvey ball notation - 25%

    25%

    Harvey ball notation - 50%

    50%

    Harvey ball notation - 75%

    75%

    Harvey ball notation - 100%

    100%

  • Colour – shades of one area of the spectrum work well, such as white (none) to yellow (mid) to green (high). Avoid more than two colours, unless you want to include a negative aspect as well, such as red (persona would definitely not use that function) to yellow (ambivalent) to green (would definitely use)

I always use Harvey ball notation, because it’s the clearest to the most number of people, and there are never any colour blindness/colour printing variation/screen display issues.

I’ve used persona profile tables in several projects now, and they were really useful for guiding interface design decisions, and finding those sweet spots with works best for both business and user and for the scenarios where the website is being used.

How to draw up a persona profile table

This assumes that you have your personas are ready to go. Profile tables are best done in a workshop situation, either within your team or with client stakeholders. This not only keeps things from being ‘designed by designers’, but gets everyone embracing and using the personas.

1. List the features and functions

Start by making a list of all the features and functions of the product you are designing. As you make this list, you’ll probably find that some functions will need to be broken down into more specific actions, or ways of using that feature. Explore this, and list it all; you can always rationalise the list later depending on the context of your project.

Example: ‘Search for houses to buy’ would break down into‘search by location’,‘search by price range’, ‘search by house feature’ and so on. I bet there would be differences in each of these item’s significance for each persona.

The examples below are taken from work done on a website about environmental information and action.

Features/functions
Background information about the environment
Background information about sustainability
How to save money
Specific actions to live more sustainably
Ways to encourage others

2. Add the behaviours

Think about the ways that personas would approach and use these features and functions. This may uncover other elements that will have differences in significance for personas, like ‘comfortable with large amounts of detail’, ‘comfortable with entering personal information’.

Features/functions
Background information about the environment
Background information about sustainability
How to save money
Specific actions to live more sustainably
Ways to encourage others
Behaviours
Comfortable with technical detail
Comfortable with content detail
Sharing information
Commenting on information
Watching online videos

3. Fold in the personas

Add each persona you have as a column next to the first column of features, functions and behaviours. If there is a certain order that you are already using when referring to your personas, use the same order.

Features/functions
Background information about the environment
Background information about sustainability
How to save money
Specific actions to live more sustainably
Ways to encourage others
Behaviours
Comfortable with technical detail
Comfortable with content detail
Sharing information
Commenting on information
Watching online videos

4. Add the ratings and heat gently

Now comes the fun part. You, your team, and your client stakeholders discuss each appropriate rating in each column for each feature/function/behaviour, according to individuals’ knowledge of personas (and therefore of requirements). This groupthink should minimise subjectivity and invite scrutiny.

Features/functions
Background information about the environment
Background information about sustainability
How to save money
Specific actions to live more sustainably
Ways to encourage others
Behaviours
Comfortable with technical detail
Comfortable with content detail
Sharing information
Commenting on information
Watching online videos

5. Observe and exploit any trends and patterns

As you complete the ratings, you may see some trends and patterns where some personas rate very highly in some areas, low in others, or cluster together in some ways. These patterns may reveal lessons that you can take to your design.

Focus on clarity

As with most things, keep the persona profile tables simple, clear and concise. Once you get into doing profile tables, it’s easy to draw up loads and loads of them, but the intention should always be to summarise what already exists in other documentation, to give others an easy-to-reference asset for the design process, and the decisions that crop up all the time.

So if you decide to include profile tables in your set of design tools, set yourself a goal to keep them to one whiteboard in the case of a workshop, and to one page (or at least one page per functional ‘area’) in a report, so that whoever else you’re working with only needs to refer to one page at a time.