Interviewer personalities: What’s best?

First of all let’s get something clear. Introvert does not mean shy and extrovert does not mean loud. Got it? Good.

There are many factors that go into becoming a good research interviewer including being able to speak clearly and confidently, use body language well, applying good interviewing techniques and take useful notes. Does being an introvert or extrovert make it harder or easier to develop into being a competent interviewer?

Introverts are reflective and passive and they tend to take up less perceived space in a room whilst extroverts are outwards-facing with their energy and can be larger than life even if they’re not aggressive or boisterous.

Does it really come down to the personality of each interview participant and their compatibility with the interviewer? Introvert interviewees may feel intimidated by an extrovert interviewer or they could find it comforting being with an outgoing and visibly confident person (although of course not all extroverts are confident). Flip it the other way and an extrovert participant could get frustrated by the passive and seemingly timid personality of an introvert researcher.

If you conduct interviews with customers and users for research how do you find your personality type has assisted or impeded your ability to facilitate interviews, if at all?

If you’re a think-out-loud extrovert did you find it a struggle to maintain self-control and stop yourself leading the participant? If you’re an introvert do you find interviewing draining and if so how have you dealt with it?

If you enjoyed this article please share it with your friends and colleagues.

Bruce Mau’s Incomplete Manifesto for Growth

Following on from my review of Warren Berger’s Glimmer I’m making available a printable version of the Manifesto so you can print it out, stick it up on your wall at work or have it handy to flip through.

Bruce’s Manifesto is thought-provoking and I think it very useful in helping designers move beyond the design-as-process mindset we can tend to get stuck in, especially in user experience where we have a fairly rigid process of research, conceptualisation, user testing, specification and implementation. I see too many designs that are confined to the most recent patterns or interaction paradigms of the latest hyped software.

Download Bruce Mau’s Incomplete Manifesto for Growth (PDF)

I’ve also designed an enhanced version of the Glimmer Principles wheel with callouts and notes.

Reproduction permission pending. Do first, ask later.

On the topic of manifestos, I found this great thought-provoking and inspirational manifesto the other day.

If you enjoyed this article please share it with your friends and colleagues.

Setting aside time to just think

There are an insane number of timeboxing techniques out there: Pomodoro, the anti-Pomodoro, Dash, (10+2)*5 and so on.

Basically the premise of all these techniques is to set an arbitrary start and end time around a task or set of tasks and focus unwaveringly on that task like you’re in a race until the timer goes off, releasing you to come up for air before plunging back into the fray like a frenzied berserker.

Whilst I can see the technique might be of benefit I have an aversion to anything arbitrary … but there is something to be said for having to resort to such techniques to overcome internal and external distractions to get the job done.

In my line of work in design and analysis I have a mix of idea-creation and domain exploration work, and the more process-like documentation and report-writing. When it comes to writing a user interface specification, research brief or test report there’s certainly a benefit in putting on the headphones with white noise, closing your email client and just crunching through the writing.

Have you considered taking the same intense time-critical approach and applying it to creative thinking? It seems like a paradox … focussing on being unfocused and letting your mind wander.

In Michael Michalko’s book Thinkertoys is a technique called “The Three B’s” method which stands for Bus, Bed and Bath – times during the day when challenges previously incubated through concentration may be solved by your subconscious. The problem is that you may not have time to wait till an idea comes to you during your next shower or while you lie in bed days or weeks later.

Banging your head against a wall is less effective than going to find the tools to do the job properly … but that’s how many of us work. We assume we can’t take time to think, to stop, take a step back and get creative. By working with that assumption we spend days doing what could have been accomplished in just a few hours.

Creative thinking does not need to be done on annual retreats or in your downtime. It’s not a privilege awarded only to visionaries and strategists. You can treat creative thinking just like you do your process work. Timebox it if you want. Put your headphones on, shut down your email client, get out your notepad and just start scrawling: what are you trying to solve, what do you know about the problem, what don’t you know, why are you trying to solve it, draw diagrams, who’s involved, what needs to be done etc.

Go read some books on creative thinking and assemble your own toolkit of favourite techniques. Last week I created an A3 poster with my favourite tools and prompts. It’s not about sitting there staring off into space waiting for ideas to come, however you still need to allow your mind to wander, to free-associate and escape the confines of your current thinking and set of assumptions.

Take the time to think. You can’t afford not to.

See a photo of the creative thinking poster I’ve put together

If you enjoyed this article please share it with your friends and colleagues.

The mobile experience is nothing like desktop

The term “mobile-optimised” implies optimising for the device whereas in my role as a user experience (UX) designer I’m primarily optimising for the user of the mobile device.

For my current project I’ve been churning out sketches and concepts in an effort to ideate and cast the net as wide as possible before market research fieldwork kicks off in a few weeks. I’ve also been sketching (with words, rather than pictures) the vision of the project and deliverable to capture the essence of what I’m designing and it’s relationship to what’s considered the parent deliverable, the main website which is being delivered by the rest of my project team although I prefer to thing of the two sites as siblings.

I’ve been getting questions about how the mobile website will integrate with the main website and I’ve been trying to figure out how I can easily show how dissimilar browsing the web on a desktop computer is to using the web on your mobile phone or mobile device.

I put together this list of typical differentiating attributes of the two experiences. In some cases the reverse will be true … for example people using desktop computers are often in a hurry and don’t have time to waste and sometimes people using mobile phones are sitting in a hospital with hours to spare. But it’s a reasonable guide that shows how polarised the experiences are. Ultimately my goal here is to show that it depends on the contexts of use for the specific mobile app – iPhone, Android etc – or mobile website you’re developing.

Desktop Mobile
Large screen Small screen
Desk-mounted monitor Screen jolting around (while walking)
Fast internet Slow internet
Have time to browse Don’t have time
Quiet environment Noisy, distracting environment
Have pen & paper to take notes Hard to take notes
Sitting down Standing or walking
Have separate phone Phone and web in same device
Focussed on task Multi-tasking
Artificially-lit environment May be in strong sunlight

Another important point is that most desktop computers will have a full 104-key (or more) tactile keyboard whereas tactile pads on mobile devices usually have 2 or 3 letters to a key. The full keyboards are typically on-screen such as on iPhones but are not tactile. This has a significant impact on typing speed and accuracy. The iPad is better when it comes to input because of the large screen size but when considering contexts of use it’s more like a laptop or desktop computer than a mobile device.

So developing a mobile alternative website is nothing like developing a standard website. Everything is different and you need to take all of these factors into account. Whacking on a mobile stylesheet just won’t cut it (but it’s better than nothing).

Have you got any suggestions for other big differences between using a desktop computer and a mobile phone or device to access information?

Check out Suzanne Ginsburg’s blog iPhone & iPad UX Reviews: User experience reviews of iPhone/iPad apps & tips on designing apps and Anders Rosenquist’s blog MobileUX.

If you enjoyed this article please share it with your friends and colleagues.

Holding the perfect workshop

I’ve blogged previously about the importance of creating the right environment and experience that allow people to participate in co-design activities. But what about when you’re just holding a workshop or brainstorming session with your own team or other professionals such as content strategists, front-end developers, accessibility experts etc. The “all hands on deck; let’s nut this out” sort of workshop where you cram a dozen people in a room for a full day?

Clearly every person brings a unique set of skills, knowledge and experience to the table so should you as a facilitator acknowledge this and seek to leverage everyone’s unique professional viewpoint or should everyone leave their identities at the door and all be treated as equal brains?

The problem I observe is that what happens is a combination of both where people wish to assert their professional expertise to add the most value to the process. Due to a lack of shared understanding about each others’ roles and capabilities that assertion typically fails because credibility and mutual respect hasn’t been established resulting in a mish-mash of unheeded contributions and stepping on toes.

The people in that room are there because they are professionals and have valuable specialist knowledge and experience they can contribute. It’s not like a co-design session where there are laypeople present or subject matter experts who are contributing value other than expertise in a technical or design field.

So to strip people of their unique expertise at the door seems counter-intuitive. Workshop and brainstorming participants should take turns at the start of the session to mention their role and background with the aim of establishing themselves as having specialist knowledge that should be leveraged by the process.

When the session delves into accessibility issues whilst everyone might have a perspective the group should defer to the accessibility expert in the room rather than giving undue heed to a taxonomist. If a point of contention arises around evidence-based user interface decisions then the group should defer to the person who conducted user testing and research rather than a copywriter.

Of course the group is entitled to question members as to the rigour and substance behind claims but this should be done in a non-confrontational manner and honestly if people aren’t confident in the professionalism of members then that’s a greater issue than the group can resolve; it’s a performance management issue and should be handled as such. Not by group lynching.

Should the group blindly trust everything the “expert” says? Absolutely not. But the group shouldn’t be interrogating people on how big a sample size they used for research or the controls they used to conduct user testing. If there are concerns about someone’s diligence and thoroughness then escalate it out of session. Not in front of everyone else. It’s disrespectful, even if it does turn out that person is a bad apple.

The problem that can arise is if the group goes around the room at the start of the session and asks everyone to introduce themselves then the opposite effect can be had where instead of building mutual respect you build mutual disrespect. You might have a situation where during the workshop someone turns to another and sarcastically spits “Well, you’re the usability expert. Let’s see what you think!”. Building that mutual respect at the outset is important and it’s vital that everyone participates in that exercise. Get everyone to contribute and state their role and skills. Once they’ve all outed themselves as experts then its hard to turn on the sarcasm later.

At the end of the day if people are prone to turn on each other and get hostile then there’s only so much you can do. People need to come primed to be respectful and positive. Sometimes the session will just turn sour because of the mix of people in the room and clash of personalities. Do what you can but don’t be afraid to pull the plug and reconvene later with a subset of participants later on.

Environment and room set up are also important. People should have easy access to the whiteboard and each other. You don’t want to set up a front-of-the-room and back-of-the-room dynamic where you isolate people at the rear of the room who then feel intentionally cut-off and will at best not participate and at worst just snipe and make negative remarks without contributing positively.

Having the right number and mix of people is also important. You don’t want people feeling intimidated by the experts in the room and don’t want them feeling lost in a sea of opinions. Even worse, you don’t want the entire process and outcome of the workshop undermined because someone wasn’t invited and later complains and invalidates everything that was decided.

Brainstorming sessions can be one of the most powerful ways of achieving results, resolving issues and bringing a team closer together. They can also be very damaging if not set up and facilitated well, so don’t be afraid to bring people into a room together but do so with care.

I recommend Robert Bolton’s book People Skills: How to Assert Yourself, Listen to Others, and Resolve Conflicts for further reading on how to facilitate and mediate better especially in tricky, confronting situations.

Michael Michalko’s Thinkertoys has some great ideas and techniques on group brainstorming and creativity.

If you enjoyed this article please share it with your friends and colleagues.

Book review: Glimmer

Glimmer is similar to Change by Design in it’s review and recommendations of applying design and design thinking to business and social innovation. The full title is Glimmer: How design can transform your business, your life, and maybe even the world.

There are three main differences between Glimmer and Change by Design. Firstly, Warren gives more recognition to graphic and visual design, and the arts.

Glimmer is also better structured in that the entire book is divided into four groups covering ten principles, being:


  • Ask stupid questions (challenge assumptions)
  • Jump fences
  • Make hope visible (visualisation and sketching)


  • Go deep (ethnography and immersion)
  • Work the metaphor
  • Design what you do


  • Face consequences
  • Embrace constraints


  • Design for emergence
  • Being anywhere

The other thing that stood out to me while reading this book is that the author Warren Berger appears to be a big fan of Bruce Mau. Quotes from Mau adorn every page and some of the ten principles on which the book is founded are taken from Mau’s Incomplete Manifesto for Growth. There’s no doubt Mau is a fantastic designer and highly quotable but the book does feel like a bit of a biography.

The author’s man-crush on Mau aside, this is a great book. I wouldn’t say better than Tim Brown’s book – they both have their strengths. I found Change by Design a better read, but with the structure and approach of Glimmer it is more practical and thus useful.

Note: Since writing this review I discovered that the previous cover of the book actually has as a subtitle “Featuring the ideas and wisdom of design visionary Bruce Mau”. That explains it.

If you enjoyed this article please share it with your friends and colleagues.

Humanitarian design is fine if done right

In response to Bruce Nussbaum v Emily Pilloton in the debate Is Humanitarian Design a New Kind of Imperialism? they both make good points although I do agree Nussbaum needs to do his research.

I love design and I love travelling so it would be great to combine both and do design work overseas for entirely selfish reasons — but I do accept Nussbaum’s criticism that the motives and intent behind people delivering design services in other cultures can influence the effectiveness of their design work.

However by following a rigorous evidence-based design methodology with an aim to implement a solution that is desirable, feasible and viable in the local context then I believe designers can contribute in a meaningful and positive way in any situation regardless of their attitude and reasons for being there.

To extend Nussbaum’s argument sighted designers shouldn’t be designing for blind or vision impaired people; non-cognitively impaired designers shouldn’t be designing for cognitively impaired people.

I think it’s absurd to expect designers to stay within the confines of their own cultural silo because apparently they are unable to empathetically and sensitively embed themselves in another culture in order to apply their design expertise.

Designers are facilitators. There’s no place for cowboy designers, lone wolves who storm in, make a mess of things and leave again. Like a catalyst, we guide others who truly understand the situation to develop the solution without us actually being part of it. It would upset me for someone to point to something I’d been involved with as a designer and label it as mine — it’s a group effort. If someone attribute a design exclusively to me then I’ve done something terribly wrong.

Even though Nussbaum’s blog post did get my blood pressure up a bit I do concede he’s got a point — about bad designers. I don’t believe such criticism can be levelled at good designers who make the effort to design and implement sustainable solutions that are relevant to the local context and that are adopted. Hell, I have to deal with the same problems of user adoption and uptake with web applications here — it’s no different. I’ve seen business software deployed with no user consultation or support and be outright rejected even though the developers believed people could be forced to change. I think the “imperialism” angle is overplayed. It really is just about good v poor or unethical design.

As far as the debate goes I think Emily Pilloton spent too much time defending the reputation and good work of Project H Design rather than clarifying Nussbaum’s argument although she did have this to say:

I cringed, but nodded along, agreeing with his assessment that too often humanitarian design is a scattershot “fly-by-night” occurrence in which Designers (with a capital D) swoop in with their capes and “design thinking” to save the poor folks.

I suggest you watch Emily Pilloton’s TED talk Teaching design for change.

If you enjoyed this article please share it with your friends and colleagues.

Illustrated user scenario development techniques

Darren Menachemson gave a presentation at the UX Australia conference a few weeks ago about storytelling in user (product/service interaction) scenario design and production.

It was a great presentation with some nicely illustrated comic strip-like examples of visually-represented user stories that had the flexibility to vary in time, context, detail and descriptive text as necessary without having to stick to a proforma. This allows designers to highlight key aspects of the interaction or go into more detail about a specific point or sequence while still maintaining the overall flow of the story.

Darren mentioned there are no rules to producing these sorts of artefacts, and I agree. But given that we’re talking about “stories” and “scenarios” I believe there are frameworks and guidelines we can draw upon to assist – however these resources should be used carefully to ensure that implementing structure doesn’t break the flow that is the beauty of this type of scenario depiction.

Story Theory

The first resource is not a single, popular framework so I’ve adopted a model that falls somewhere between the vague (and therefore useless) and rigid models to something that is adaptable and useful.

Story theory is about writing stories. The models for story theory describe how best to structure a story in order to provide enough depth, interest and momentum for the readers of that story. Much like any tutorial on photography – which is something I wrote about previously.

The core elements of plot and character development have been around since Aristotle and as our illustrated user scenarios are unlikely to be as complex as a multi-threaded 300-page fiction novel then those basic linear concepts are still applicable.

I would like to present an eight-step plot structure developed by Glen Strathy that is a useful guide to thinking about and planning the plot for your scenario:

  1. Story goal: What is the goal of the story? What is the point we want to make? With user scenarios is it some pain point in an interaction with a product or service? Or a pleasant interaction? Success or failure? What’s it all about? Why are you preparing this scenario?
  2. Consequence: What will eventuate if the goal is not achieved? Essentially – what is driving the user in the scenario to go through the actions. It’s unlikely to be a life-and-death situation like you might have in a fiction novel but there must be something that is driving the user.
  3. Requirements: The steps in a process the user must go through to achieve the goal. This will likely be different to the steps you might have in a UI spec. There will be some overlap if you’re describing the interaction with a user interface but think about what other things the user must do before, during and after that UI interaction to actually complete the whole process from beginning to end. This is where personas will come in handy.
  4. Forewarnings: “Forewarnings are the counterpart to requirements. While requirements show that the story is progressing towards the achievement of the goal, forewarnings are events that show the consequence is getting closer”. This is what gives the raw, real-world aspect to a user scenario. The scenario shouldn’t depict a controlled laboratory environment with perfect weather, zero stress and readily-accessible help. Once again, refer to the personas and remove the optimal parameters to make it real and relevant.
  5. Costs: These are things the user “might be forced to endure in order to achieve the story goal”. Possibly not an aspect you want to explore with a simple user scenario but think about it – it might be relevant, it might be important particularly for scenarios depicting failed or sub-optimal interactions.
  6. Dividends: “Dividends are not necessary for the goal to be achieved. They may be unrelated to the goal entirely. But they are something that would never have occurred if the characters hadn’t made the effort to achieve the goal”. Think about the secondary benefits of a product or service.
  7. Prerequisites: Self-explanatory, the order in which events must take place for the goal to be achieved. Think about what happens when that sequence is not followed and whether that results in a deviation or the consequence.
  8. Preconditions: Roadblocks. Obstacles. Once again, refer to the real-world aspect of the scenario. This is not taking place in a controlled laboratory.

It seems unreasonable to try and cram all this thinking into a five-frame illustrated user scenario – but you should at least consider the framework and where relevant draw about this preparatory thinking to ensure you deliver a holistic story that achieves its goal and delivers the message.

Use your personas to flesh out your character(s) and make them believable. Different parameters of a persona profile will influence how the story plays out.

Decide what the setting of the story is and describe it both through illustration and the story.

Remember that you can annotate and caption your scenario so you don’t have to be too subtle about it but don’t inadvertently prioritise aspects of the story with black-and-white text captions that detract or confuse.


The second framework is a bit more defined. It’s a four-step format called Situation, Task, Action, Result (STAR) and is generally known for its use in recruitment by interviewers and job applicants to describe a work experience case study.

It’s certainly a simpler model than the story theory discussed above but could result in describing aspects of a scenario rather than a sequence that flows, and without the passage of time there is no interaction.

STAR is quite basic. Describe the situation, the setting of the scenario. What task or goal does the user have to perform? What action does the user actually perform? And what was the result of that action? Are they successful in performing the task? If not, what are the consequences.

Hopefully these two resources might give you some ideas when preparing your illustrated user scenarios and user stories. As I mentioned before, Darren is right – there are no rules. But it’s important to consider all these different aspects of telling the story so the audience can relate to the story, can feel empathy for the user depicted in the scenario and understand the context, the challenge and can explore different ways of looking at a product or service.

Quotes from and references to used with permission.

If you enjoyed this article please share it with your friends and colleagues.