With sun, sea, and a tropical 30 degrees C outside, no wonder people kept  saying that UXLX felt like a vacation. You might think it a pity to be indoors. Luckily day one of the conference kicked off with some cracker material that justified staying inside.

Storytelling for User Experience – Whitney Quesenbery

One of the first workshops of the day was kicked of by Whitney Quesenbery. In her workshop she tried to teach the audience the importance of telling stories during the design process, both to clients and team members. One of her main messages is that stories aren’t a broadcast transmission, but always create a connection between the audience and the storyteller:

• the storyteller shapes the story;
• the audience form an image;
• the storyteller and the audience affect each other;
• the most important relationship is between the audience and the story.

When a UX designer did research and shares his knowledge with the team stories can be a great way of doing this. When done right the storyteller retells the important parts of the stories the users told him, thus creating a connection between the design team and the user.

In order to become good storytellers we first must learn to become active listeners. We need to really be willing to hear the story people (users) are telling us and understand what’s it all about. Being an active listener means we have to encourage the story to be told further, by asking open questions and giving non-verbal feedback.

During the workshop Whitney actively involved the audience by giving several tasks. She focused on the following subjects:

• Story structure: structures give the story a shape and help the listeners/readers to understand it better. Is it a me-they-me structure, do you want to turn it into an adventure structure or should it be a contextual interlude? The way you set the story up can help engage people in the right way and lay focus on the right part of the story (like the product, the user or the process);
• Story context: context grounds the story in a specific place and time. You may want to emphasize (or change) the location, time, history or something else to help the listeners to understand it better.
• Purpose in UX: stories help drive UX work in several different ways. Do you want to share a success story and share what made this product so great or is the focus of your story to facilitate a brainstorm and do you want people to think in a different context?;
• Format of the story: there are many ways to tell a story, you can decide how. Is it written or drawn like a comic? Should it be a formal presentation or a light conversation starter?
• Imagery: imagery gives the story emotional resonance. By adding details about the sounds, smell or motion of the environment or a specific person you can pull the listeners into the world you are creating.

These tasks were closely linked to the book she wrote with Kevin Brooks called Storytelling the User Experience., so if you want to know more I would definitely check it out (also check out our excerpt). All in all it was a very interesting workshop with loads of stories. And as Whitney said: “what is design but a story?”

Become a UX Team of One – Leah Buley

UXers may know about being asked if you’re an innie or an outie, but if Leah Buley’s research catches on, you might also be a giraffe, bee, beaver, or penguin. Confused? They sum up the types of people that might be described as a UX Team of One. In her interactive and workshop with a lot of new material (such as I can’t find pictures of the gorgeous icons she used for each animal), she took the group through planning their futures, and thinking about ways to combat issues as the lone UXer.

However, her outstanding and memorable takeaway (including beautiful icons sadly not caught on camera but bound to end up on badges) was that of the four types of UX Teams of One. She sees them as a spectrum (most of us start at number one and move down), and classifies them as the following:

1. The Crossover (giraffe) has recently come over from another field. (Their long neck is from foresight).
   As their challenge relate to focus, access and skills, the strategies are to do with collaborating and DIY research. A key point to remember is that clients won’t allow for research do it should just be built in or ‘done on the sly’ (our podcast with Sam Lader on design research also talks about this).
   Some methods include using MAYAs Heuristic Markup, The Five Second Test, and competitor images (even getting the clients to collect them as homework!)
2. The Doer (a bee) is a knowledgeable person in a company without a UX department — they usually have to do things beside UX or move departments a lot. As they are held back by being brought on too late, or not valued, they need strategies to focus on professional relationships, visibility, and ROI.
   Some relevant methods included Liva Labate’s UX Health Checkup, product definition workshops (stakeholders repeatedly draw and disucss their product vision, as after a couple of rounds they’ll be far more aligned) and “Lunchtime UX” listening dates with other key team members.
3. The Builder (beaver) has been in UX for while on point of starting UX team.
   As their issues relate to relationship management and politics, the strategies are to align with business and build out a team. Methods included ongoing internal surveys, case studies and pre-meetings (1-to-1 reviews of docs with each key stakeholder before a key design review)
4. The Independent (lonely penguin): those that are freelance etc. Literal team of one
   They need to promote themselves, be legally savvy, and set their own terms (e.g. using a project brief). What’s more, they need to be known for something (as Leisa Reicht has blogged about).

Buley has been evangelising the UX Team of one for a few years now, but those who saw her talk a while ago (or looked at the slides) should definitely see it again as there is a whole lot of new information in preparation for her book-in-progress of the same name.

Skeuomorphs: The Good, The Bad, and the Silly – Andrew Watterson

Skeuomorphism is the act of using cues from the old to make new things feel more familiar. It has been applied for a very long time and can in our practice be a great way to introduce people to new technology and interactions. Some of the better known examples of skeuomorphs are the sound of digital cameras when you take a photo and the fake engine sound electrical cars make so that you can hear them approach.

When launching a product with a totally new way of interacting, like the iPad, you see that skeuomorphism can be an easy way to let people get used to the device. Watterson gives examples like the bookshelf in iBook and the old fashioned look of the contacts page. But at the same time he points out that there is still a lot of debate whether this approach is really the best way to go. There are a lot of people who have strong opinions for or againts, like our writer Rahul Sen is the recent article ‘The IxD Bauhaus: What Happens Next?’  I believe that there is a balance and that skeuomorphism can definitely be a good thing, but that we should always try to keep challenging ourself to also look at different ways of approaching the interactions. It’s just one way to reach what we want, but surely not always the only and best one.

Watterson’s conclusions regarding to this topic:

• Use skeuomorphs to add a satisfying and nostalgic emotional effect;
• Bridge gaps between what people are used to and a new method with skeuomorphs;
• Question whether you’re skipping the opportunity for innovation by using a skeuomorph;
• Don’t mismatch your functionality with a skeuomorph.

Picking your Neurosurgeon’s Brain— Susan Dybbs

For most of us, the closest we get to seeing what happens in an OR is through TV shows. However Susan Dybbs showed us not only what a surgeon sees when they’re carrying out telesurgery, but how we can use participatory design methods to understand highly expert and tacit processes.

Starting with Terry Winograd’s observation that designers have limited time to process things like how something feels like is in the tacit domain, Dybbs pointed out the issues that designers have when trying to create interfaces for highly expert systems such as telesurgery interfaces — the designer can’t get anywhere near the understanding that the users have of what happens and what is working. She resolved this by reating a toolkit of a mockup process with clipping (words, chunks of information, pictures of xrays etc) and then got surgeons to talk/make through their experience of surgery.

One of the most interesting insights from this method was being able to show the difference between what users say they need and what they actually use. In the case of surgeons, this might be documentation that is for legal reasons but never used in actual surgery, information they didn’t actually need (surgeons thought they needed to see the room view but actually didn’t) and vice versa (e.g. sideness — which side of the body you’re operating on, is a minor but key piece of information in helping a surgeon orient themselves with telesurgery).

Her tips for best practices:

• Create a toolkit (nothing is more scary than a blank piece of paper)!
• Do your research (sort original themes)
• Precondition your participants (e.g. photojournal, or just storytelling/pre-interviews)
• Keep it rough + impermanent
• Think aloud (helps show mental models)
• Be flexible (e.g. meet people at their comfort zone — help them make collage if they don’t want to do it).

Creating the Ultimate Experience: UX + CX + CRM — Stuart Cruickshank

Can you have a relationship with your oven? Stuart Cruickshank argued that you could. How? Through a combination of acronyms: UX, CX (customer experience) and CRM (customer resource management).

CRM has traditionally looked at strategy, business, and technology, but thanks to social media, a new branch of this known as Social CRM has emerged that also looks at engagement and conversation through empathy, emotion, authenticity, transparency. A great example of a company using social CRM is Zappos — their model means that their customers have a great experience and feel empowered, while the company gains advocates and profit (they have no marketing budget!)

On that oven? The Art Home Electrolux project attempts to do this (an exciting restaurant in Paris uses all Electrolux products, and the cook provides tips about cooking, meaning the customer could go home and cook what they got at the restaurant, as well as continuing the conversation through social media.

After a lot of conferences talking about service design, it was refreshing to have an alternate take on service systems UX could get involved with. As Cruickshank pointed out that the end of the talk, while CX and CRM have more visibility at the corporate level, at the end “experience is the goal”.

For those interested in the topic, he highly recommends Paul  Greenberg’s CRM at the Speed of Light (4th Edition).

Effective Design Documentation Without a Fuss — Dan Brown

Despite the growing interest in living prototypes for UX, it looks as if design deliverables won’t be going away any time soon. Dan Brown (who we interviewed earlier this year) tried to trick the attendees into saying it might be or otherwise, but most UXers know to always say “it depends”!

What is design documentation? Brown defines them as “an artefact, defined by a team, to create a project, whose purpose is to move a project forward.”

He suggests that many designers forget to think about purpose and progress (at worst making some projects stand still), as above all, documentation should inspire action.

Brown breaks down design documents into different types: clarifying approach, justifying decisions, comparing multiple approaches. Each of these should be handled differently, just as your structure should change if you’re writing for a different audience (e.g. developers vs C-level).

He finished up with a look through the Eight Shapes Unify system he took part in creating. His rationale for the system is that most existing templates in Word etc are a waste of time as they force you to fill in blanks.

The best takeaway in regards to writing was to “be a journalist not a comedian” — in other words summarise first rather than having it at then end (common in comedy but in journalism known as burying the lead).

Designing by Doing: Bringing Agile Thinking to UX Practice – Anders Ramsay

Agile development is one of the hot topics in todays UX scene, so several talks at the conference today focused on this topic. In Anders Ramsay’s workshop he didn’t jump into the agile process itself, but used the approach of agile thinking and showed how we as designers can use it in our day to day practice. He did this by giving several tasks:

• Paired interviews: this method comes from paired programming, where two programmers sit behind one screen and together write the code. In paired interviews you let two users interview each other instead of you interviewing them one by one. According to Ramsay this is a great way of getting insights you would normally be unable to collect, since the users themselves know what to talk about and what is interesting to know. By letting them conduct the interviews and write down the interesting material you can collect great amounts of raw data in a short time;
• Agile personas: in agile development you don’t design all the details at once and you try to minimize the amount of documentation. The idea behind agile personas is to create very light-weight artifacts out of research data (like you collected through paired programming). By letting the entire team check the raw data and detect trends you are able to share with them important insights. When you after that write the agile personas (real name, main characteristics and quotes) you have a great starting point for your future discussions;
• Story flows: use some of the user stories you collected in your user research and prioritize them. After this you can start adding tasks to each story and prioritize these as well. Even when you are not doing scrum you can still use story flows to get a good overview of what you want to create and especially what’s the most important thing to do first.

Ramsay’s workshop was very engaging, although a bit chaotic. He was well able to show everybody the power of agile thinking, although there are still so many other things to agile thinking that would have been worth sharing… one of the aspects I find most interesting is the daily standup with the entire team, to get a good feeling of what the current progress is. You don’t need to scrum to have the benefits of this way of working together as a team.

Earlier this year we interviewed Mark Baskinger, associate professor at the School of Design of the Carnegie Mellon University. In the interview Mark talks about drawing ideas and shares his thoughts about the differences between industrial designers and interaction designers and how interaction designers can use sketching to communicate their designs better.

Mark Baskinger teaches industrial design with an emphasis on form and interaction and conducts Drawing Ideas workshops

Note: the first minutes of the interview we had minor problems with the audio. No worries, this will go away…

Why is it that when people think of involving a community in design their minds immediately turn to surveys and polls? Enough already. Involving a community in your design process doesn’t mean making the community make the design decisions… this is why we’re dreaming up new ways of engaging a community, qualitatively, in the design process for the Drupal 7 User Experience Project.

What’s so bad about a poll?

I think there are two key reasons why voting should generally be avoided in community design practice:

1. Your community is (probably not) made up of designers

what colour would you like? Which icons do you prefer? Do you want your navigation here, here or here? Which of these three visual design treatments do you like best?

When you’re out doing design research in person, you don’t ask people where they’d prefer their navigation. Rather you use conversation and observation to gain insight into who your users are, what they need to do with and any other information you need in order to make good design decisions. Why should it be any different online?

Humans, at the best of times, are pretty bad at telling you how they’re going to use things and what configuration will best suit them. We know that, don’t we? So what makes us think a poll is a good idea? A
nd what do you, as a designer, do with data that says that 67% of the people surveyed prefer green? You don’t know anything about *why* these people like green, or in what context they actually hate green. This data contains no real insight.

2. Voting is like fast food
cheap

It is easy and initially feels good, but it leaves you wanting more

A
 vote is super quick and easy to set up and similarly it is quick and easy to participate – you can sit back and watch the numbers roll in. ‘Look!’ you can shout, ‘see how many people are involved in our project!’

It’s easy to be seduced by the numbers. But ultimately a few quality interactions with your community are worth more than 1.000 empty gestures. Just as when you compare numbers in a qualitative study and a quantitive study, it’s not always a matter of more is best. Ultimately everyone is left wanting more. The designer wants more insight and the participant more engagement.

We need to be more thoughtful, more creative and willing to work a little harder in designing ways for communities to engage in an open design process. With that in mind, here’s a few activities we’ve been trying out on the D7UX project.

Crowdsourcing Wireframes

Extracting Existing Community Knowledge

This is an exercise that we first did on the Drupal.org project and are now running again for D7UX. Essentially we invite people to draw up a wireframe (in whatever medium they prefer) of a part of Drupal they think needs improvement. This time around we also asked people to make a quick screencast walk through to give us some more context and understanding of both the problem and the solution. Participants post their work either to their own blogs and give us a link or to the Flickr and Youtube groups we have for the project.

There is a reasonable amount of effort involved in participating in this activity, so we tend not to be flooded with responses. This is good, for a number of reasons:

• The data is quite tough to analyse.
• The people who do participate really do care about the project and the problem and have given it some real consideration. Each submitted artifact then becomes a discussion point for the rest of the community to gather around.

Working with a developer-led community like Drupal we do tend to get our ‘wireframes’ in pretty high fidelity. In fact, a wireframe for us is everything from a pencil sketch to a live implementation. Especially on a project like D7UX where there is a ‘back story’ to everything and almost every idea has already been considered and discussed at length. It is a great way to draw some of these conversations out earlier in the project than might otherwise be the case.

Crowdsourcing Usability Testing

Capturing Scale, Sharing Our Process

Continuing in the crowdsourcing vein, we have also been trying to capture the scale and diversity of the Drupal community by recruiting willing participants to help us do some user research on the project. We first attempted this exercise during the Drupal.org project but it didn’t really take off. Despite lots of interest, no actual tests emerged. So, it seemed like a good idea but we needed to tweak the process a little to make it more accessible and easier to engage. So far we’ve run one round of CrowdTesting for D7UX and happily, we’ve had about a dozen people around the world participate. And the information we’ve been collecting has been put to great use already.

What did we do differently this time? Rather than just putting the concept out there and saying ‘go for it!’, we have scheduled a series of dates throughout the project when testing will be undertaken. I’ve also been a lot more prescriptive about what needs to be tested and how to test it this time around. I provided a downloadable document with the materials (we’re testing paper prototypes at the moment) and a script to follow, plus some interviewing tips for newbies.

Participants conduct a short test and post the results to an online questionnaire. We also encourage participants to video their test and post the video to our Youtube group (or elsewhere if they prefer). The posted video is particularly helpful in allowing us to analyse and contextualise reported findings.

What are the benefits of this activity? Not only do we gather more research data from all around the world (and yes, we are still coming to terms with the challenge of languages other than English), but we are also making user research much more accessible to people who might otherwise never had exposure to it. We are really hoping to continue to promote the practice of user observation throughout this project. And we hope to see real user observations used as evidence as we work with the community to debate the best approaches to various aspects of the interface.

‘Pimp Your Admin’

Extracting Existing Community Knowledge

When we first started on the D7UX project, we had a feeling that lots of people out there were ‘hacking the interface’ of their Drupal admin to make it more usable for their clients. We knew this, of course, because we’d seen a few instances of it. It struck us that this would be a great way to do some ‘requirements gathering’: to take a look at as many ‘hacked interfaces’ as possible and see if there were similarities in the changes that people were making to the admin interface to make it more human friendly.

And so we came up with ‘Pimp Your Admin’ in which we invite people to walk us through the customisations they’ve made (or that they regularly make) to the admin interface. We launched this at a conference, Drupalcon DC, where we sat down with people and did the screen recording and interviews in person. But this is also an online activity and members of the community from around the world have since prepared screencasts sharing their own personal interface modifications. This has been interesting both for us and for the community – you don’t really get to see other people’s admin interfaces very often!

As we suspected, there are definite ‘themes’ in the changes made to the interface and even at this early stage we know that several of these will be mirrored in our proposed design. We’re continuing to capture this material throughout the project too.

Having the opportunity to work within this community context is an amazing challenge and opportunity, we’re really trying hard to be as thoughtful about the way we engage with the community as we are with the design work we produce but it is a constantly evolving process of trial and error and refinements.

Want to see where we’ve gotten with it so far? Be sure to check out our recently released Initial Concepts and Directions and be sure to let me know what you think!

Top image by yoroy

Have you read Sketching User Experience by Bill Buxton? Then you must. Right away. Even stop reading this article here. Well not really, but I hope I conveyed my sense of urgency. His book and his work has been a huge inspiration to me. Most directly it is a strong influence on the workshop I sometimes teach called “Sketching for Interaction Design”. Recently I taught the class to a group of 20 budding user experience professionals. Afterwards I received some feedback and there was one meme that seemed to have permeated throughout the class: Multiplicity.

While Bill Buxton writes about a few apects of sketching that make a sketch valuable: quick, rough, disposable, cheap, I think he doesn’t quite put enough emphasis on one important definer: creating multiplicity. Doing it rough makes it quick and disposable and obviously cheap, but having multiplicity of ideas juxtaposed together is the key ingredients that makes sketching one of THE defining tools for all disciplines of design: interior, fashion, industrial, graphic, architectural. And it is multiplicity that in my mind truly defines how design works!

Why is it so important?
I love the name of a company I recently gave my sketching workshop at (coincidence? … I doubt it.) called “Bond Art + Science”. Don’t know what the Bond means, but saying “Art & Science” to me says something really important about the state of design today. That it is a conjoining of these two sometimes diametrically opposed parts of culture.

I believe the UX community at large though has been mostly attempting design through science. Whether qualitative or quantitative the drive for “data” has been the main form of practice for UX practitioners at least those in my sphere of influence. And while data is important, it is only half of the question when it comes to trying to develop ideas.

But what is Art. Oy… I’m not really going to go there. But I will say that artistic modes of creativity usually follow non-linear, exploratory and experimental paths of engagement. While many might think that art is created in a single blast of brilliance, and sometimes it is, much art is a path of sampling and modeling and evaluation on themes of aesthetics over time.

My first connection to this process came when I saw a Degas exhibit. First, you were introduced to the “master pieces”. You’ll see why I put that in quotes in a minute. But there amongst these amazing paintings were other works of craftmanship. Sketches and sculptures all playing on the same theme as the paintings. The craftmanship was of such high quality that if I put these in the room by themselves without the final reference, I would think these were final works of art. But they weren’t and some might even question whether Degas really wanted them to see the light of day outside his own work studio. They were not complete subjects but rather explorations on the path of telling his final story on canvas.

Sketching is the juxtaposition of creative change, and associations whose close context allows for deeper and deeper creative translation and transformation on iteration

These were sketches in the most important sense. I’m not sure quick and disposable, nor cheap, but definitely done in multiples. Seeing them juxtaposed one might attempt to create a path towards the final work. However, it is more of a post modern deconstruction. Elements of this and that from different sketches keep getting combined and re-combined, altered just slightly here and there. While a recognizable relationship exists in each sketch, their non-linear path is difficult to trace. Did sketch A inform B or visa versa on the way to C?

This is the craft of sketching. It is not merely rough redundancy for volume’s sake, but rather the juxtaposition of creative change, and associations whose close context allows for deeper and deeper creative translation and transformation on iteration.

The process’ goal if not intentional, definitely leads to a planned serendipity–joyful accidents that lead towards useful ideas. Accidents require two parts minimally to collide together. In my experience in design, though, the really juice accidents happen as multiples increase.

The picture on the right is from one of the best storytelling movie studios in the business today, Pixar. A huge influence on my thinking about creativity and design was the Museum of Modern Art exhibit, “Pixar: 20 Years of Animation,” in New York City in 2005. Throughout the exhibit was example after example of how juxtaposed associative thinking using the tool of sketching led the creative team through design/art rendering decisions.

The sketches above are from the movie “Cars”. One of the things that separates Pixar (and I’ll say Dreamworks) from other animation studios is the level of creative detail. This takes a huge amount of trial and error to get the right level of balance so that the story is maintained, but enough delightful & unexpected moments are added to increase audience engagement. This can really only be done through rapid, modeling of the stories so that pacing and well audience reaction can be gauged.

During my workshop, I tell my students that sketching is both a collaborative and a personal process. That communicating ideas is an important part of sketching when collaborating, but it is more important to use sketching as a tool for crafting ideas the way we use software for any other craftsman tool. You can achieve ideas without it the same way you can do cabinetry without one tool or another, but the results are always better when you are using the right tools.

I also say that it is a personal tool because many UX practitioners feel time & budget pressure and asking for a new stage of the development process would be looked at negatively. But so long as the designer achieves their results within the same time frame and don’t require changes to other people’s workflow any designer can easily add sketching to their personal tool kit without any disruption.

Try it!

Top image by tico24
Sketches by Edgar Degas & Pixar