Empathy & Sympathy: UX Skill

The profession of Experience Design requires you to have empathy for the people who will use the service of product. The best designers I have ever met are highly emphatic, very humble and of course very able. Empathy is however often confused with sympathy and it is often not well understood who much we need to work to create empathic designs. This is ultimately what is man by "delighting he customer". 

Empathy is the ability to understand the emotions that someone else is feeling. Empathy is about recognising the emotions that someone else is feeling and being able to identify with them, to put yourself in their shoes. You share their feelings.

Sympathy on the other hand means that you can identify the feelings of another, not that you share in those emotions. You acknowledge hardship, but don't necessarily feel the emotion. 

It's possible to have empathy for someone and have no sympathy, for example if someone does something stupid and hurts themselves (think back to all those Fail videos on Youtube), you might feel their pain but feel no sympathy. On the other hand, if someone hurts themselves coming down the stairs, you might feel both.

Active empathy is when you react through sensations and feelings to the emotions of another. You might feel stressed if they show fear for example. You experience active empathy from when you are a baby, through sensing emotions physically. 

Cognitive empathy is your ability to understand and identify other people's emotions. You develop this around 3-4 years old, when you begin to understand that people experience the world differently.

Compassionate empathy is your ability to understand and identify with emotions, but also feel spontaneously moved to help. This is something you develop yourself through a deep understanding of yourself and others. 

Having empathy is the first necessary step towards compassionate action. Nurses, medical doctors, counsellors, teachers,...all require compassionate empathy. So do experience designers. When you have empathy for the people who will use the product, or the service, you enter into their experience of it. 

It's even tougher for experience designers, because they need to develop empathy for a large number of people who they will never meet. There lots of tools that we can use to cultivate the empathy required to design something great, as well as triggering compassion in the team. Personas have long been used to remind everyone of the people we are designing for. Storytelling allows us to role play the experiences, and develop a greater understanding and awareness of user needs. Dogfooding (using your own service/product) allows you to experience everything first hand, with the caveat that it is one kind of experience amongst many other perspectives. 

Emphatic people are good communicators because they can undersand that people can have different perspectives.  They know how to allow room and respect for those different points of view, and can change their communication style to adapt to the situation.  It allows you to get a software team on board and to listen and learn from to all kinds of people. 

Emphatic experience design examples: 

• Shared language 
• Pre-populating form fields
• User research (listening & observing)
• User journeys

It pays attention to the feelings of the people using the product / service.

Sympathetic experience design examples:

• Help text
• Documentation
• FAQ
• Surveys

It ensures that the people using the software / service can accomplish their task.

Empathy is crucial for experience designers, much more important in my opinion than the ability to code or do visual design. Without an empathy-driven design process, it's impossible to create something people will enjoy being a part of, a valuable and delightful experience.  

Facilitating collaborative design workshops

Collaborative design workshops allow you to get decisions made in an inclusive, rapid and multidisciplinary way. They ensure that there is a shared understanding and ownership on a new project, and that it is set up for success right from the start. If you have never facilitated before, do not be fooled, it is much harder than it looks. Make sure you prepare yourself well, and before undertaking any critical workshops, give yourself a chance to get plenty of experience beforehand. Being a great designer does not qualify you to automatically be a great facilitator. There's a whole bunch of skills to develop and to fine tune before you can manage even the hardest of groups. In a collaborative design workshop, you:

• Define the MVP of the project so that everyone know what the requirements are and what the scope of the project is
• Map the customer journey so that everyone is aware of the user flow
• Sketch out the various screens that will be needed against the user flow
• Take notes of any changes to existing screens and how those will be done
• Make lots of decisions together
• Align as a team before you start building

Collaborative design is a ensures that design, dev and the business are working together and iterating quickly, so that we have a better result due to better alignment and shared information and knowledge. We also fail quickly and as a result we all learn a lot more. Collaborative design allows us to rapidly prototype things. Prototyping is is better than talking: it is thinking with your hands. It forces us to try things and learn from them rather than talking about them and trying to make to decisions based on assumptions.  We move past long-discussions in meetings into action fueled, effective workshops.

The wall is the new desk:

Get your group working together at the wall, whether it's displaying and discussing design, or creating a user journey, or brainstorming. Get them to make all work visible. Also working together at the wall means that they will be physically active, which keeps the energy up in the room.

Running these workshops is fun for the group, and also a lot of hard work. As a facilitator, there are a bunch of things that you need to do to ensure the session runs well, and that you get the most out of your time together.

Your role as a facilitator:

Think of yourself as a group nurturer and a process guide.

• Support everyone to do their best thinking
• Encourage full participation
• Promote mutual understanding
• Reach inclusive decisions
• Cultivate shared responsibility
• Reach the goals you set out to achieve
• Have breaks

How to run your session:

You need to prepare. It's really important to have a clear understanding of the goals you have for the workshop, and that you plan activities that will enable you to get to the outcomes that you need.

1. Pre-workshop

•  List your top 3 goals for the session (More than 3 in 2 hrs is usually difficult)
• Work out what you need to accomplish to get there
• Decide on activities that will allow your group to achieve these things
• Carve up your time into activities, time boxing each one meticulously (schedule breaks, introductions, ice breaker and a little spare time)

You will have a well prepared collaborative design workshop all ready to go. Making sure that you have time for each activities is really important. If you don't timebox well, your session will be rushed, out of focus, and ultimately won't allow you to succeed. If what you want to do won't fit into the time you have, then you need to be realistic and cut down on the number of things you;re trying to do in the session. It's always better for morale to have 2 shorter session than a whole afternoon in a workshop.

Supplies:

• A kitchen timer (nothing works better than a big red tomato...don't use your phone, people will ignore the ring)
• Lots of sharpies of different colours
• Sticky spots or stars
• Index cards
• Blutack
• Post-it notes
• Large roll of paper or butchers paper
• Whiteboard markers
• Water and snacks

2 - Workshop time

There are a few things that help when running these workshops, and starting with ensuring everyone understands the point of the session and knows how to behave during the workshop is really important. Never assume people will be ok to follow you blindly, you'll need to make them feel comfortable before they trust you to get them where they need to be.

• Spend 5mins introducing the session and its rules:

The parking lot (keep the team focused by writing all out of scope ideas on cards that are placed in the parking lot wall).

The timeboxes (Show then your timer, and explain why you are timeboxing and how its helpful to them).

Workshop conduct (No talking over others, no shouting, no closing down other people's ideas, no chatting during brainstorms...).

Write the activities you're going to run on the whiteboard, along with the goals of the session, and how much time is allocated to each one.

• Run an icebreaker

This is especially useful if you have a large group who don't know each other well. For groups who do, it's a great warm up. An ideal activity is giving them a sheet of paper with circles on them, and asking them to fill in each one to represent a different thing in 5mins. It gets them drawing and doesn't give them time to worry about it. Get everyone to share how many they managed to complete and show what they drew. It usually leads to some giggles and sets you off in a good atmosphere.

• Run your activities

This is where you all get to work hard. As a facilitator, it is your job to keep everyone within the allocated timebox, to keep the group energy up, to ensure everyone is heard, and that all of the ideas are on the table for consideration. You'll also need to deviate from the plan sometimes, yet still get the right outcome in the allocated time. Interrupt people when they are off topic and ask them to use the parking lot, which you will sort at the end of the session. Encourage the group to work together, support individuals who are struggling for whatever reason (shyness, intimidation, bad behaviour, etc...) and keep control of the session. If you allow the group or any individual to not play by the rules, your session will flounder very quickly.

Don't tell them what you think, help them get there themselves by asking a lot of the right questions. It will have a lot more impact and you won't have to explain everything. The best facilitators can keep it fun and focused at the same time. Practice makes perfect.

• Close the session

Make sure that you end the session on time. People will not want to come to your workshops if they have a reputation for running late. Remind everyone what the goals were and sum up what you achieved as a group today. Make sure any actions that have merged from the work have an owner who is responsible for following up or doing something. Ensure you group ideas in the parking lot, and ask the group whether a further session should take place to resolve those things. If there's no clear grouping, and lots of unrelated things, ask the group how they'd like to handle those.

3. Post-workshop

As your group scurries off to enjoy the rest of their day, you still have a little bit of work left to do:

• Photograph all the walls and whiteboards
• Throw away paper that has served its purpose
• Roll up and keep any that you need for further work
• Wipe whiteboards
• Tidy up
• Write up the workshop outcomes together with photos of the work on a collaborative space for everyone to refer to
• Have a well deserved cold drink and kick back

Resources:

Designing with Stakeholders? Accelerating the design process through co-creation (UX magazine)

Facilitating Collaborative Design Workshops – a step by step guide for rapidly creating a shared vision for execution (Jason Furnell)

Encouraging Participation and Fun During Collaborative Design Sessions (UX Matters)

Become a design leader in your organisation (Surface digital)

Design thinking and the facilitation process (Patrick Glinski)

Facilitator's Guide to Participatory Decision-Making (Michael Doyle)

Make Space: How to Set the Stage for Creative Collaboration (Scott Doorley)

photo credit: boxman via photopin

What does "Agile" mean for design?

There is still a lot of confusion around what "Agile" means in terms of software development. There is even more confusion now that Lean has been popularised. Agile is really not a complex thing to define, in fact the Agile Manifesto does it perfectly: Principles behind the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Things to debunk when you hear them:

• "We don't do the full Agile thing, we pick the bits that work for us" - the Manifesto is non-negotiable. If you're not following these principles, you are not being Agile. You might have very good reasons for doing so, but it's still not Agile. There are degrees of Agility though...

• "We are Agile we use Scrum and Kanban and <insert tool here>" - Using tools developed for the Agile team does not make you Agile, in the same way that buying a Chris Boardman bike does not make you a world class cyclist.

• "Agile is a process/method/framework" - Agile is a philosophy

• "You start with the backlog" - You start with creating the backlog

• "Agile is faster" - Not necessarily, it takes the time it takes

• "Agile scales naturally" - Not necessarily, in some cases it can be very hard to scale

• "If you use heavyweight tools, you can't be Agile" - You can still be Agile and use Prince2 for example

• "You're either Agile or waterfall" - It's not a binary choice, there are degrees in between

• "It's always the same Agile environment from project to project" - Needs will change according to the team so let them structure their environment

• "You can't do Agile with remote teams" - Yes you can, you need to create a working environment (even if it's virtual) that works

• "Agile means you never have to write documentation." - You will need to sometimes, it's about having just enough

• "Agile is simple" - It seems deceptively simple when you read the manifesto, but it takes time (and patience) to put in place

• "You can learn Agile from a book" - Nothing teaches you better than being part of a truly Agile team

What about Design then?

The Agile manifesto mentions design once, around self-organising teams. Having design as an integral part of a software delivery team is new to a lot of companies, and there are still a lot of problems in teams around how to work with the designer. Designers are not all the same: they have different strengths, come from varied backgrounds, and have more or less experience with software teams. While some of them will be a good cultural fit for software, others will struggle. If you have been trained to have ego about your work, and to never show anything until it is perfect for critique...then Agile is going to be a big change.

Lindsay Ratcliffe wrote a manifesto in her book "Agile Experience Design".

Agile Experience design is:

Inclusive rather than elitist

Emergent with direction rather than upfront

Integrated and collaborative rather than handed of the fence

Considerate of customer, business and technology needs rather than biased toward a single factor

I see this manifesto as supplementing the original Agile manifesto. Striving to uphold these values and ironing out the creases is all part of the fun, all part of learning what works and what doesn't. Different teams need different tools, processes and people. What works for one may not work for another even if the circumstances are similar. These manifestos help us stay true to Agile, when we have decided to adopt it. How you go about that is another matter entirely!

 photo credit: jakuza via photopin

The difference between Usability and Experience Design

I hear a lot of people using "Usability" and "Experience design" interchangeably. This is quite a big mistake.  They are both important for product success, both are tested differently, both are successfully crafted differently, and they both need quite different focus and skill sets. Usability answers the question: "Can the user accomplish the goal"?

Experience Design answers the question: "Is the user delighted"?

Imagine you go to a retail website to buy a pair of jeans. You arrive at the homepage and easily find and navigate to the jeans that you want. You pick your size and the colour. You add them to your cart without a hitch, pay and check out. Job done: awesome.

This is usability. Your customers can easily buy products off your website. They understand what to do, it all works as expected, it's easy, and fast.

Ok. It's 5 days later and your jeans have arrived, but 3 days later than promised. They are the wrong size and the wrong brand. You can't find out how to send them back and ask for your order to be filled properly. None of this information is with your package. You go to the website and after 10mins of searching find a phone number. You're not sure whether it's a customer service number or not but you call it anyway. You listen to 5mins of options to choose from on a recording before you even get to speak to a human. Finally a tired sounding man sighs and then says "whateverjeansdotcomcustomerservicehowcanihelp?". You begin to explain your problem and he interrupts you and transfers you to somewhere else. A woman picks up and asks you what you want. You explain your problem again. She tells you that you have to go to a post office and send the package back yourself. Then you need to fax them the receipt and they'll reimburse the postage costs. She needs to refund your money for the jeans to you and needs you to go back to the website, order and pay all over again...

Will you be ordering from here again?

This is experience design. I can delight you by taking full responsibility for my mistake, and ensuring that you not only get your order the same day, but that you also are compensated for the mistake. I can also take into consideration that because I sell jeans, sometimes people will order the wrong size, so I can delight you by not penalising you for it. Instead I will include in every package a ready paid empty mail bag so you can just drop it in a post box and return it at no cost. I might determine that my customers want to experiment and try products they have never bought before. I can create a whole experience around that so that people can select a whole bunch of clothes, we ship them out to you, you try them all on and send us back what you don't want to keep. We'll charge you for the ones you keep, you don't need to go back on the website to do anything.

Delving into your user journey, seeing that this is a single purchase, I question needing to have to add it to a cart. After all in a store you wouldn't grab a shopping cart or a basket if you are about to buy one item. If I wanted to improve on the usability, I might investigate this in more depth. Can I reduce friction even more? If you are a repeat customer, can I remember your payment and shipping details for you too?

Can you see any other opportunities? I'd be learning about my customers as much as possible. Not just about the things that they tell me they want, but also by using ingenious methods to gain insights into the things they never knew they wanted. What are the unarticulated needs? What is my competition doing and how can I be a better? How do I give you a totally kickass experience that you will love and remember? How can I reach you on an emotional level?

If I have a physical store, I'll do more. I'll want to ensure that the entire experience of our brand, be it online or in the store, is always the same kind of awesomeness that you deserve as a customer, or even as a potential customer. What do you think the Amazon physical store would be like if there was one?

The Four Seasons hotels have found a common pattern where people enter their hotel room, throw their bag on the floor and coat on the bed, and then drop into the armchair...and exhale. They refer to this as something like "the exhale moment". You want to savour that moment. They have ensured that everything is in place to make that moment especially amazing. The seat itself, the proximity of reading material and the mini bar...(more about this in Tim Brown's book). Where is the "exhale moment" in your software product? I think it has its place in experience design as well.

Things you might talk about when considering usability:

• Accessibility
• Interaction design
• Layout
• Path to completion
• Funnel analysis
• Time on task
• Eye tracking
• clicks
• ...

In short, you are in the minutia of user interface design.

Things you might talk about when considering experience design:

• End-to-end customer journey
• Personas
• Behavioural
• Real world context
• Scenarios
• Ethnography
• Social science
• Perceptual psychology
• Design Thinking
• Environmental design
• ....

It's a much larger subject area than usability. It involves a lot of diverse and complex skill sets, and requires a solid understanding of psychology, business strategy, design principles, brand strategy...it is cross-disciplinary.

As a developer, you should know all about usability, especially if you are a front-end developer. You should have a fantastic grasp on how to lay things out and know all the rules and how to break them. This is not the sole responsibility of the "UX" person on your team. It is your responsibility too. It's fundamental if you want to create a quality software product. Usability is the responsibility of the team.

The real crux of the job for experience designers is being outstanding at experience design. This does not mean that as an experience designer you don't care about usability. On the contrary, it's one of the keys to success. On the other hand, you should know where the areas of improvement are, how to find out about the ones you don't suspect, know how to benchmark and measure quantitatively and qualitatively, and know the customers. You should know what they want, what they want but can't articulate, what they need from your services/products, who they are, who they might be in future, how to persuade them, know how they behave in every different scenarios, be able to understand if this reconciles with the current business strategy and know what to do if it doesn't.

Where does visual design fit in?

It is fundamentally important to have excellent visual aesthetics for your product. There is plenty of evidence about what a huge difference it makes and I rarely find anyone argue that it isn't. The mistake here is to think that this is the only aspect of design to take into consideration when actually designing a software. When you are designing a service, there will always be visual touchpoints and these need to be cared for as much as any other detail in your work. If the experience is awful like in our jeans buying example above, do you think you'd be more impressed with the service if the website and packaging looked stunning? On the other hand, do you think that you would even consider buying jeans from the website if it looked terrible?

"Design"

It's not "usability design" it's just "usability". Why does this fall to the designer on so many occasions? It is the responsibility of the whole software team to ensure that what they are making is at least usable. It's called "experience design" because it is a practice of design. Design is fundamentally about problem solving. Innovation is a design problem, for example. Design is about solving problems by finding out what they are exactly, and then executing the best solution possible. Jonathan Ive does a lovely job of summing up what it means to be a good designer in this interview. He's an industrial designer rather than an experience designer, but still design is design.

I think that the following quotes sum it up neatly:

"Design needs to be plugged into human behavior. Design dissolves in behavior." -Naoto Fukasawa

"A lot of what we are doing is getting design out of the way." -Jonathan Ive

To conclude, if you are worrying exclusively about what colour that "Add to cart" button is, rather than  considering whether you need a cart at all, and finding out what to do instead...You're not doing experience design.

Wabi-Sabi in Experience Design

Wabi-Sabi, simply put, is the ability to see beauty in simplicity, the ordinary and the imperfect. English is too clumsy a langage to explain it fully, and I am too much of a clumsy writer to do so well, but you can think of them like this: Wabi: The ability to make do with less; A "wabibito" is a person who can make something out of less parts than anyone else. It means content with little, and taking pleasure in the ordinary.

Sabi: The gift of time; To grow old gracefully and with dignity.

Wabi-Sabi aesthetic is also described as "imperfect, impermanent and incomplete". The beauty of those things is found in their simplicity, their unpretentiousness, their humbleness. They are unencumbered by anything unnecessary but not to the point that they look or feel clinical, rather their raw essence alone is left. They are not the center of attention but are unassuming and command a quiet authority. Wabi-sabi isn't just about the aesthetic though. It's also about the object giving you a feeling of serenity and having a connection to the object.

"Pared down to its barest essence, wabi-sabi is the Japanese art of finding beauty in imperfection and profundity in nature, of accepting the natural cycle of growth, decay, and death. It's simple, slow, and uncluttered-and it reveres authenticity above all. Wabi-sabi is flea markets, not warehouse stores; aged wood, not Pergo; rice paper, not glass. It celebrates cracks and crevices and all the other marks that time, weather, and loving use leave behind. It reminds us that we are all but transient beings on this planet-that our bodies as well as the material world around us are in the process of returning to the dust from which we came. Through wabi-sabi, we learn to embrace liver spots, rust, and frayed edges, and the march of time they represent." (Tadao Ando)

Wabi-sabi in Life:

I've always loved the wear on my beloved denim jeans and old shoes.The wear on my moleskins that I dragged around the world with me. My cherished old family photographs, yellowing and frayed at the edges. Our old children story books from when we were small. I love asymmetrical things and simple design. I find magnificent beauty in less. I found joy in fewer possessions, less waste, big passions, being in nature and an uncomplicated life. Not striving to have it all and not trying to predict what my life should be like next year or next month or next time. Learning to be content in the present, and finding enjoyment in every day things. Wabi-sabi exists in my life, and I wager that it has its place in yours too.

Wabi-sabi in experience design and Lean/Agile teams:

As experience designers and as members of Lean/Agile teams, I think we are very Wabi-Sabi in our work:

• Our work is never finished, and so always incomplete
• We try to fail fast
• We try to limit waste
• We never release anything that is perfect
• We try to keep our experiences simple and unencumbered, without losing the humanity in them
• We strive to keep them subdued and honest
• The work we do will always evolve and age, and we will work with the downsides of design decisions we made earlier
• We never do "big upfront design", so our worldview is ever-changing and intuitive
• Our emphasis is always on working code and not on beautiful looking documentation. In this sense each artefact is one of a kind
• We know that our design will evolve, so we think about the present moment rather than projecting far into the future
• We work in iterations, in an organic way
• We adjust to change easily and avoid deliberations
• If we can do it with less, we do
• We pay attention to the ordinary (all those habits people develop to deal with bad design)
• We ensure our software "fails gracefully"
• Users "wear in" our designs and their relationship with the product changes over time
• The more people use our designs, the more they connect to them (like your relationship to your email account)
• We reuse code and design elements where we can
• The team has a history and a shared knowledge that seeps into the product

Resources:

BERG London have a beautiful blog post written by Tom Armitage on Wabi-Sabi right here.

Leonard Koren wrote a book called "Wabi-Sabi for artists, designers, poets & philosophers".

Marcel Theroux discovers Wabi-Sabi through the experience of the Japanese tea ceremony: "

15 things Ray and Charles teach us

There's an awesome essay by Keith Yamashita called "15 things Charles and Ray teach us" (PDF), that I found via SwissMiss. I wanted to share it with you and summarise the 15 points here for those who don't have time to read the whole thing, but I encourage you to have a gander, because it's really beautifully presented and well written. I've applied the 15 points to experience design of course :) 01. Keep good company

Surround yourself with other awesome people, it will inspire you. For us experience designers it means brilliant people from different backgrounds, areas of expertise, industries...Making the effort to get out and meet them, and spending some time learning and sharing.

02. Notice the ordinary

Notice the simplicity in people's desired interactions and design them in that same way. If someone wants to drag and drop an item with a finger, don't make a complex dropdown menu. Use patterns that work well and are familiar to people where appropriate, so the learning curve stays manageable. Don't over-design things, keep it simple.

03. Preserve the ephemeral

Don't be afraid to design something that will work for a while and then be replaced by something new. I keep notes on things that I made to serve a purpose for a little while (lean start-up style), and then replaced and redesigned as I discovered more about the user needs. Those things in turn get redesigned again. As the user's relationship with the software evolves, so should the design. In the same vein, keep note of fads in experience design. They reflect a culture and a need at a certain time. There are interesting patterns there.

04. Design not for the elite but for the masses

Design things that will work on all sorts of devices, make your designs responsive, and cater for all kinds of connection speeds. Make your interaction design easy for most people to grasp, and allow your visual design to tell a story that many will appreciate. Ironically, observing extreme users will help you identify needs not so easily spotted in the average user. The designs you craft as a result will delight the majority of users.

05. Explain it to a child

In the same way that toddlers are able to pick up an iPad and use it immediately, your should strive to design software that is so simple to use that even a child could pick it up. I think this can apply to accounting software as well as games and anything else. This is not to say that it is designed for children, mind you. Your product/service/process ideas be solid enough that you can explain the essence of them to a child and have him/her understand with no difficulty. In fact you might get some pertinent questions!

06. Get lost in the content

Reach out to subject matter experts, read up on the new industry you are designing for, immerse yourself in the needs of users and the lives they lead...understand what their world is like, how it looks form the inside of their world, and what they aspire to. Understand the technology, speak to developers, try it out.

07. Get to the heart of the matter

Make sure you are solving the right problem, and articulate it clearly and concisely. Don't make documentation for documentation's sake. Just what you need, when you need it, aimed at the correct audience, and get to the point swiftly.

08. Never tolerate “O.K. anything.”

Fight for great design, in your work and in others too. If you are working in a lean way, ensure that your product is a great MVP, not an ok one. "Just enough design", does't mean "ok design". If you think something isn't good enough, that it could be better, say so.

09. Remember your responsibility as a storyteller

Collect user stories, tell them in a convincing way, either through role-play, customer journeys, a video clip,  presentations, illustrations...Tell the story of the design clearly, and in appropriate detail. Get good at storytelling. Read up on this and practice, it's a really useful skill.

10. Zoom out

Never fail to see the big picture.

11. Switch

"Never get Bored". Don't restrict yourself to designing websites, apps or whatever. Expand your horizons and apply your skills to whatever you can, whatever comes your way. Design a garden, a process, a book, a shop,  a shoe, a room, a city, a bus or a spoon. Anything.

12. Prototype it

And early on.

13. Pun

Have fun. Play on words, play with ideas, with software, with images, with objects...can you use something in an unusual way? Have fun for fun's sake and share it with others.

14. Make design your life… and life, your design

It is awesome when you are lucky enough to find a career path that you love so much that the line between work and play ceases to really exist anymore. I think that's when you can say that you're in the right job. Make your own design for life, your own philosophy, and live it.

15. Leave something behind.

Our work lives through the people we work with, those who use our products, our clients, our friends. Beyond our craftsmanship, we should have the kind of positive presence that allows everything we stand for to emerge and remain once we have gone.

8 qualities of great Experience Designers

Designers of all kinds, in particular experience designers, come from a variety of backgrounds. They are different in many ways, and will always disagree with each other to some extent (minimalism, Helvetica, logo size...the list is long) but great designers have a number of qualities in common. I am fortunate to know a bunch of really brilliant experience designers, and was thinking about made them so great. I found that I could distill that into 8 main qualities that they all have in common.

 1. Discipline

To engineer a great design you must have great respect for all of the rules, and break them when they need to be broken, not just because you can. You also need to continuously learn about new interaction patterns, seek out interesting designs, and read up on up and coming methodologies in all areas that touch experience design. Working on your project alone will teach you more than you knew before, but won't be enough to sustain you in good ideas for long. Great designers are always seeking out the cutting edge of their discipline, and spend many hours reading, learning and practicing.

2. Ritual

It can be tempting to cut corners when you have designed something a thousand times before. It's important to keep the rituals in place, and keep looking for a new way to do something, question everything until you are sure that it has a legitimate place in your design. Explore, find inspiration first, then ideate and find a solution. Don't get sloppy.

3. Craft

You must be attentive to the details, check your design, and communicate it effectively to the team.  Wireframes should be clearly annotated and thorough, assets should be high quality, the end product should be excellent. You should be a master of your craft, at every stage of the design. This means that you need to identify any areas for improvement and actively work to get better at them all the time. The craft of experience design goes beyond deliverables such as wireframes, sketches, interactions, and so on, but also includes facilitation skills, communication skills, presentation skills, diplomacy, and more.

4. Awareness

This means awareness of new technologies, design patterns, trends and so forth, but also awareness of the current project space. You are never designing a noun (an app, a shopping website...) you are designing a verb (shopping, discovering, enjoying...). Ensure that what you think you have been asked to make is really what the business and the users need. Make it your business to be aware of the full implications of what you are designing (does it impact the world in a positive way?). How is the evolution of the design being perceived by others? Are your stakeholders scared of your unusual design? Be ready to explain, show, convince at all times.

5. Introspection

Take some time on each project to be alone. Even on a fast Agile, collaborative team. Even if it's just 10mins. On every project there are a lot of people to listen to and work with, from people in your team to people who will be using the product once it's made. I noticed that great experience designers take a little time alone on each project to think slow. Everyone I have ever met has an opinion on how a design should be. Has a decision been made because it's easier to agree and move along, or was it legitimately thought through? Do you really agree with the decisions that have been made? Are they really for the best?

6. Focus

Decide on what the end goal is for your design at the start, and focus on making it happen. This saves you from adding in unnecessary features, trying to design for too many needs, and making something that is a complicated Swiss army knife rather than a slick, easy to understand design. Define your design language and stay with it. Go for a colour or a set of principles and stay with them. It is important to be able to pivot and change course quickly, but it's also important to focus long enough on what you're doing so this can be sensibly judged.

7. Commitment

At the start of a project there is always excitement, everything is new and shiny, full of potential. As you make your way on the path to completion, the best designers enthusiasm remains high, and they continue to commit themselves fully to the work. While we all have ups and down on projects, and it's important to acknowledge that there are low energy days, we still need to give ourselves to the work fully each day. Beware of situations where you have more than one project on the go, and be quick to voice any problems you see up ahead. It's all too easy to commit to more than one project and then see all of them turn out mediocre. This will exhaust you and you won't get the satisfaction you get from doing great work. Don't muddy the water. Dieter Rams during his whole career has been committed to particular principles of design. Do the same, even if your principles are different.

8. Love

If you don't love the work you are doing, if you don't love the act of designing, you will never truly do any great work. It's really difficult to be focused and committed to something you don't genuinely have an interest in. All great designers of any ilk really do love what they do. If you don't, then find what it is you do love and go and do that. There's nothing satisfying about being mediocre at your job. Pure love for what you do is a nourishing thing, that helps you grow as a person and drives you to want to improve and break barriers. It lights up your life. There is a real blur between what is considered "work" and "play" when you love what you do.

An Experience Design Manifesto

 Thanks to Lizi Hamer for all the help and for letting me steal off her! I learnt lots along the way.

"I believe that all software should be designed, using a human-centered approach. Interactions will be obvious, seamless and pleasurable. I will not refer to you as an "end-user" but as a full person, a participant in the software's story. I will fashion experiences for you that do not degrade you, and that allow you to engage with our work in an appropriate manner. I will endeavour to measure the success of our software, not solely based on hard metrics, but also based on your own evaluation of it. I know that you do not necessarily perceive the world in the same way that we do, and I will do my utmost to be mindful of not inflicting our subjective experience of the world on you. I believe in sweating the details, so that you don't have to. I believe in setting a consistent design language, so that you can feel comfortable quickly. If I can do it with less, I will. I believe in ensuring that our software fits seamlessly into your day and life, by remembering that it is not the centre of your universe. Finally, I will ensure that everyone on my team is aware of you, and that they are mindful of your needs and respectful of your time and energy".

Marie-Claire Dean

Pairing for designers (Agile)

  It's important to collaborate because it allows the team to become a powerful unit, full of common knowledge and questions. Each individual has a clear view of what is going on and has the power to affect the product direction and evolution. If as a designer you do not collaborate with the rest of the product team, you essentially deny yourself this right. By pairing with the QA, (front and back end) developers, BA, PM and anyone else who is part of your team, you gain all of the necessary perspectives on the project to really understand the product you are making. You should ideally always be working with another person and never alone. This allows the team to cut out a lot of time draining and uninspiring inter-team formal communication, and actually focus on the product.

More importantly, the design then belongs to the whole team, and is no longer treated like a sacred cow.

How to pair with a developer:

You will need a whiteboard and a few whiteboard pens, a shared screen and a mouse and keyboard between you. Use the whiteboard to communicate your design ideas, and work together on solving design problems that crop up and technical problems that you encounter as well. This way you are designing that is feasible technically, every single time. You don't have to have meetings about the design, where you show wireframes or photoshop files. You don't have to have talk about possibly trying this or that to get over a hurdle....you can just do it right now, together. Experience design needs to be user-centered but also technology centered. Weirdly enough, a lot of designers forget the latter. If you need you need to make something in photoshop to go into the design, then do it together and then make it into working code right away. Working this way is a LOT of fun and the product that you are making comes to life quickly. Your client will be super happy because you have made something tangible in record time, and you now have something that works to put in front of users. Yey!

It is tough though. Be prepared to sweat. As a designer you have to know your job well enough to do it on the fly with little preparation. You have to let go of perfectionism and aim for a minimum viable product that still fulfills your user needs. Remember that you will iterate. Better still, because you have a working product to put in front of users really quickly, you can include solid feedback in the next iteration and not make all those features that nobody ends up using.

Why you shouldn't code (even if you can):

The whole point of pairing is that you can share the load together, and bring a wealth of expertise and experience to the product. Imagine that you are designing a login screen. It's always useful to start with the action, so tell your programmer pair to make a login button. While s/he is focused on the button, and on the minutia, you are focused on how the entire design hangs together across the whole product...all the other screens that you know about, and all the design decisions that you are about to have to make. You are the big picture person and the other is the small picture person. If you are coding, you will pretty much only be focused on that button. While that button is being made, maybe you are drawing out the login interaction on the whiteboard and the next screen.

Where to start?

"Build what you can with what you know" is the slogan I like to use. It is tempting to want to get all of the information about everything up-front, but the reality is that by actually making something you put yourself in a better position. You can modify, start again or carry on the next day. Iterate. remember that there is never really such a thing as an "End product" because if it's any good, it evolves and there is no end. The more you think about it, the more the whole team thinks about it...the more it is misunderstood by the team. Everyone forms their own assumptions and ideas of what it is and how it works and what it looks like. It all becomes more like a field of dreams. Sometimes we even agree as a team, whilst all thinking we are agreeing to whatever we each have in our heads. Actually we are more confused than ever before. Keep it tangible. Make the product now and keep making it. When you talk about it, point to it. Everyone can see what it is, what colour it is, what shape it is and how it works. It couldn't be clearer. All of your focus should be on your product and not on your process. Show your work often to your client, and let them use what you have made so far. It makes for a better conversation than a meeting that refers you to wireframe 180(a).

But what if it's all wrong?

Throw it away and start again. You are throwing away some code, that's all. This is far preferable than the potentially huge cost of  a design lead time (where developers are twiddling their thumbs waiting for you to come up with a design). You may have made some mistakes or maybe yes, t is all wrong, but by collaborating you now have shared experience as a team, you have learned to make something together, and you have probably alos won client trust because you have shown that you can make something that works in a morning rather than a week or month. Even if it is wrong, you have failed fast and learned something valuable from that experience. The team will be a lot closer. You will share your valuable design knowledge with team members and learn things from them as well. You all win. A lot is to be gained from jumping in and making something that is wrong rather than spending a lot of time making nothing, trying to fill in all those gaps (we talked about those in the last post). At the end of the day, you might find that you have pursued 3 different approaches and made all of them in the same time it would take to go away and wireframe everything meticulously on your own.

What if you have layers of management to get approval from before you can make anything? 

Working in an Agile way requires the client to work closely with you, so that you can make decisions quickly. If your client is very removed from your project, then it will be hard to be Agile. You will have to make documentation that gets sent up the management chain for approval and this might take some time. In this case, you have fallen into a waterfall. Fear not though, this is fine. As a good BA friend of mine says: This is exactly the situation for which waterfall was designed for". If this is not the way you and your team want to work, then you need to have a chat.

How do you ensure that the product remains user-centered and ends up being right?

If you are in an Agile environment, you need to ensure that while you are making, you are also discovering and learning how best to evolve your work. The diagram below shows that you should be focusing all of your energies around the product. The further you are from actually doing code (making), the further you are from the center of the concentric circles. Tasks on the outer rim might include user interviews for example. That isn;t to say that these tasks are less important or devalued, they remain deeply and crucially important, because they give you direction and ensure you make the right thing. Anything in between the outer disc and the inner one are things that...we...fall in between. To ensure that you are not just blindly making or lost in a world of research and no making you should be working on tasks on the outer and on the inner discs simultaneously. The stuff you do in between is up to you. Additionally I split the whole thing into examine, define, create, verify. Most tasks will see a full revolution.

To finish: Cultivate Li:

Jade cracks along its natural contours, which adds to the artistry in working with it. Jade carvers incorporate the breaks into their work, bringing into evidence the natural elegance and great beauty of these lines. They are said to rely on the stone's natural "Li". Each and every project has its own "Li". Allow it to be there and learn to work to turn all of the challenges into something beautiful in the end. Take advantage of them. Drop the fear and the resistance, trust the integrity  and capabilities of the team. It takes more than just your immense capacity to make logical decisions to succeed. You need to be invested fully so that you can trust your instincts, trust your heart and trust your gut. (More about "Li" in this excellent book: "Awake at work")

Tangible wireframes: "the wirefoam"

The Situation:

Designing in an Agile development environment requires transparency, clear communication and frequent delivery. Teams will work in sprints (typically 2 weeks) with a focus on making software rather than documentation. Wireframes are useful for designers to work out interactions, potential pitfalls, communicate design ideas, and are very useful to the development process. They are a visual representation of the layout of features and content of a user interface or website, and I would also add, in many cases how things in it get used and behave.

They are however considered documentation, and we should always prefer working code over docs. This means that it's not going to be very efficient to lock the UX team away for a few weeks to design a whole load of stuff that the development team can't actually build, because of limitations and restrictions. These can be technical, or financial, or even related to resources available amongst many things. The planning of the user experience might be awesome, but it's useless to user and the stakeholders unless it is functional. Although this is true, it doesn't mean that there isn't a place for them and that they shouldn't be used. There are more efficient ways to make use of them and get answers quickly, rather than how they are traditionally presented.

The complication:

As experience designers we are often not the ones to have total sign off on the end solution. A lage team of people will have a say and add their 2c before anything is signed off to be developed and later, deployed. It's time consuming to get round to presenting ideas to everyone, it's hard to get all the relevant parties in a room together because they're inevitably very busy, and it can create a lot of extra work as well (collecting different team member and stakeholder concerns, needs and ideas). Additionally, presenting on a screen, although it gives everyone a good idea of what you're talking about, can fail to get the message across. The reason for this is that a wireframe does not look like a finished product, and is static. Even if your wireframe is an interactive Axure prototype, it's still a picture. It isn't as engaging as as it could be and isn't easy to use in a collaborative environment.

"Plant a seed, grow a tree"

Often, we will not launch the final version of a software feature, but a functional version, designed to be improved on and evolved. This is very useful to us as experience designers, because we get a chance to collect live data and user impressions on the stripped down functionality before adding bells and whistles. This means that we add the bells and whistles that are actually required by users, rather than guessing what may be best in advance. A stat that gets thrown around a lot is that 80% of users use 20% of features. All those extra bits appear like a barnacle effect over time, the more people get involved and the longer you have in my experience. It's good to start with just what is needed, before discussing any further features.

A resolution: tangible wireframes

Instead of showing your design on a screen, even projected onto a wall, make it tangible. It's pretty easy. All you have to do is print it out, stick it on some foam board, and then use a box cutter to make it into jigsaw-like pieces.

For your team:

Stick some blutack on the back and stick each feature up on the wall for the whole team to see. This allows people from your team to come up and move things around to get a feeling for the experience. You can stick up some poster sized paper up there too and allow people to write their thoughts, ideas and concerns up. I have a separate one for technical concerns.

For stakeholders:

In a stakeholder meeting, you can bring the "wirefoam" along and introduce each feature bit by bit and pass it around the table for everyone to have a good look at. The fact that they can hold it and piece it together with other bits will make it an easier, more productive conversation. On the back of each piece of wirefoam, you can write down the name of the stakeholder who requires the feature, and for what reason. This is particularly useful for forms for example. Taking a piece of wirefoam off the table and putting it back in the bag (or even the bin), is a very effective way of moving the conversation on to the next thing, now that it has physically disappeared.

It's also quite good fun, so you're likely to have happier people around the table and more interesting outcomes from those meetings! It's easy to add and take away features. It makes it easy to role play interaction. It's a great documentation tool, because you can take photos of all the different combinations of pieces that people come up with, or show how it evolved for example.

Have fun :)

ROI of UX

photo credit: baldiri The scientist in me is always trying to measure everything, trying to find patterns and insights, trying to quantify and accurately qualify...It's no surprise that the ROI of UX is a topic that has been on my mind for some time now. Business people understand numbers and I learned that using them in ways they understood often won me time or budget or both. I'm working on various ways to measure the effect of the UX team in organisations, mainly because it would help us not only understand its value but also clearly see any bottlenecks. I would like to speed up the UX process, but in a way that greatly minimises risk. If you speed up a process, and decide to spend less time on certain things, there is always going to be a trade-off. I'd like to be able to accurately say by what percentage we traded-off, and what the effect of that was.

Agile and UX:

There is a lot of debate at the moment on how to integrate UX in an Agile development process. I think the key to that is live site/software metrics, remote user testing, and more metrics. I think that to include UX in the Agile process, you have to also favour working software over documentation, same as in any of the other disciplines in our teams, like QA or BA for example. This means pairing with a Dev and getting things done immediately for low risk features, is preferable to drawing up wireframes. It means sketching with a pen and paper, and updating those sketches during feature meetings, with other team members and stakeholders. Draw it and hold it up for everyone to see: "This is what we're talking about".

If you deploy features without doing live user tests, you can still check how well they're doing by analysing the analytics on the live site. This is why it's so important to have sophisticated analytics, beyond Google Analytics and other free solutions. Just so we're clear, I don't recommend doing this for innovative solutions, but rather for things that the team already has experience with (i.e. How many highly innovative contact forms have you designed in the last 10 years?).

There will be a trade-off, but if we accurately measure how effort, time, and so on are affected, we will have an idea of how well this method worked. If we have no idea of how productive the UX team is, or what the value of their time is, we are essentially working blind.

Measures:

Before you even begin thinking about design, I think that it makes sense to agree what the ROI is for different stakeholders. It can be different for different groups involved in the project, and you might not be able to please everyone every time. Keeping tabs on which way the balance is tipping is really important.

Hard measures might be:

- Conversion / Acquisition

- Lead generation

- Retention

- Traffic

- Viral referals

- Employee productivity

- Cost savings on Dev etc...

- Decreased time to market

Soft measures might be:

- Engagement

- Customer / User satisfaction

- Brand loyalty

- Product/service adoption

- Awareness

- Ethics

- Team morale

The value of UX:

For every $ invested in UX, there is a ROI of $2 - $100.

The UI accounts for:

- 47%-66% of the total project code

- 40% of the Dev effort

- 80% of unforeseen fixes required

An equation might go something like this:

Value = (Benefit - Cost ) / Cost

This can shed some light on what the ROI is, once the cost of the team has been taken into account.

In conclusion:

If we can measure the exact ROI of UX, we can demonstrate the value of the UX team, their work and also justify the need for research when it is necessary. Often the complaint around UX is speed. We can speed up the UX process by sketching, measuring features when they are live, and evolving our designs rather than working to create a final and highly polished version at launch. We can calculate the trade-off of using this faster deployment method rather than the more traditional process of doing lots of user testing up-front. There will be times where it isn't appropriate, and knowing the numbers allows us to justify this to the business. A caveat for the faster deployment method is that the UX team must be very senior and experienced.

I liked Dr. Susan Weinschenk's video about the ROI of UX, enjoy!

My creative technology toolkit

[caption id="" align="alignnone" width="500" caption="...and so this is how someone might use my spaceship to get to work."][/caption] photo credit: pasukaru76

You don't really need anything at all to come up with an innovative or interesting idea, but if you're going to make a habit of it, then it's probably a good idea to get comfortable. I make sure that I'm exposed to a large number of different types of ideas by reading news ranging from electronics industry breakthroughs to new health fads to software releases right through to newly published research papers. I want to know what's new, what's cool, what works, what doesn't and how to do new things.  Once I've consumed and digested all this new stuff, I go for a walk, meditate, practice Pranayama...whatever I need to do to let it go. It might seem counter productive, but I want to retain the knowledge and not the detail. I don't want to copy something by mistake or get too focused on one thing. Once I'm ready to go, I like some quiet time to work on whatever my problem is today, and having access to my "toolkit" helps this somewhat unpredictable process. If it were predictable, my output probably wouldn't be very innovative.

You might find something I use below to be useful to you too. I wonder what tools others in the business of innovation like to use.

Inspiration & Reference:

For me this section is about books, because the web is too distracting at this stage in the process. Sometimes if I'm stuck or just I need of a little lift, I'll read a few paragraphs from one of these. I also refer back to practical book for reference quite a bit too.

Amazon kindle - it was a birthday present and I really cannot part with it, it's awesome and gives me access to all the following books anywhere I go. The eInk is far better for your eyes that the backlight of the iPad. I prefer it for reading.

Materiology - This book is for creatives who "rely on materials and technologies architects, designers, stylists, artists and the like, from students to experienced practitioners."

Sketching user experience - Probably my favourite UX book by one of my favourite UX people.

Processing for visual artists - A good book on Processing with an emphasis on being creative with it.

Making it: manufacturing techniques for product design - It's good to know how stuff is produced and this book covers over 90 different processes.

Gamestorming: A playbook for innovators - A little bok full of brainstorming ideas for when you feel stuck.

Resonate: present visual stories that transform audiences - A book about how to present your ideas. Never underestimate this part of your project.

The 10 faces of innovation - IDEO labs gives us a nice little book on innovation and how to encourage it in your organisation.

The lego minstorms NXT 2.0 discovery book - A "How to book" for making cool little robots from Lego

We are the real experiment: 20 years of FACT - The book from the Foundation for Art and Creative Technology, beautiful.

The art of innovation - The story of IDEO labs, I'll write a summary for you on of these days.

Getting started with Arduino - This one is new for me, but I think it's important to make things beyond software so this is a good place to start.

Work materials:

These things are absolutely indispensable for me. I need to be able to get my thoughts out and into the world in a quick and simple way. I try to stay away from the computer or any technology until I sort of know where I'm heading. The following have been really useful during my PhD research especially.

Index cards - one card per idea

Marker pens -lots of different colours

Blutack, glue and sticky tape - to put index cards up on my walls

Post-it notes - the more colours the better. I use them to write caveats on idea cards or warnings

Whiteboard - good for diagrams

Lego - nice way to bring to life a user path. Check out Lego's Serious Play.

Hardware:

Basically you'll want to be able to get your hands on and play with anything that's relevant to your current project, business area or idea. It's nice to be able to have access to anything that's new and interesting, so that you get to learn how to use the technology, how to program for it, and can start to imagine new uses for it. A current hardware list might look something like this:

Laptop, iPad2, iPhone 4, Android phone, Kinect (+ FAAST and the SDK), Camera, Projector, Earphones / Headphones

Other stuff:

Samples (RFID tags, circuit board, LED, bottle caps...) - it's good to have bits and pieces to play with to hand, but you should spend time contacting hardware manufacturers asking for samples when you have pinpointed something you'd like to use. There's nothing quite like making a proof of concept to find out of your idea is feasible.

Software Development Kits (all sorts) - these are like gifts for geeks.

My yoga mat - It's good to move around and get some breath in my body, and it's important to just stop what I'm doing sometimes and give myself a break. Yoga allows me to rest my mind quite effectively, and then the ideas come flooding in afterwards. It just works, what can I say!

What I aim for each time:

1 - To design an innovative and effective solution for a problem

2 - To make a proof of concept

3 - To communicate the solution clearly

I'm hugely passionate about Human Factors, so (almost) all my solutions have the user at the center. The technology I choose to work with s not incidental, but rather one that I think my user will appreciate. That doesn't necessarily mean that I only pick things that they already use, but I do make sure it's going to be an easy transition for them. If the current technology is a bit too geeky but still very cool, I'll work on improving the layman's experience with that. Sometimes really innovative things come exactly at that juncture.

Happy making.

Kinect hacked, sliced and diced

Released in November 2010, Microsoft's Kinect has created a bow wave amongst the more technically minded communities. Most computing departments in Universities own one and they're doing very cool stuff with it. You will have all seen the long stream of videos under the tag "Kinect hacks" and you will have all seen it do some things it wasn't intended to do. In this post, I want to talk about why it's actually such a complicated device, and where it's going next. If you read this blog, you more than likely not only know what it is, but you know the gory technical details too. I won't spend too long on that as a result, but just in case this post goes "mainstream", lets introduce ourselves to the box before we talk about thinking outside of it:

Microsoft have introduced it like this:

"Kinect brings games and entertainment to life in extraordinary new ways without using a controller. Imagine controlling movies and music with the wave of a hand or the sound of your voice*. With Kinect, technology evaporates, letting the natural magic in all of us shine...Controller-free gaming means full body play. Kinect responds to how you move. So if you have to kick, then kick. If you have to jump, then jump. You already know how to play. All you have to do now is to get off the couch...Once you wave your hand to activate the sensor, your Kinect will be able to recognise you and access your Avatar. Then you’ll be able to jump in and out of different games, and show off and share your moves."

The technology isn't all Microsoft. It uses range camera technology which interprets 3D information from a  continuously-projected infrared structured light. This was made by Israeli developer PrimeSense. The 3D scanner system uses a variant of image-based 3D reconstruction. Its motion and voice sensitive, make it a "Natural User Interface", because no controller is needed. The depth sensor has an infrared laser projector together with a monochrome CMOS sensor, which captures video data in 3D under any ambient light conditions. GamesRadar has a nice techy review of it that you might like too.

"Think Tom Cruise in Minority report" is another way I've heard it described. A big thank you to MIT for making that a reality, but it wasn't really made for this either. It was made to play Xbox games. Microsoft have however embraced the hacking of its newest offering and have made available an SDK (thank you for this MSFT).

There are other options to the SDK, and until very recently there wasn't one. Adafruit ran a competition for Kinect drivers and Hector Martin won, releasing the code available at OpenKinect. There's also a Google Group if you're interested and loads more support online. PrimeSense made available their motion tracking middleware NITE, which is worth noting. Kinect-Hacks is a great site if you want to get hands on.

Anyway...now we know what it is, back the point of this post.

It occurred to me how different the user experience has become. I don't have any insider information, but I reckon MSFT spent a small fortune in the user experience for the Kinect.  I can well imagine how much testing much have been so that when a child places itself in front of it, all of the expected things happen. This makes for a really easy gameplay and allows someone to really "be the controller". There have been some really useful usability reviews such as the one by Jacob Nielsen, one by Steve Cable and the comparison by Sheryl Yu Lin. They show that although it's a good product, the overall opinion is "could do better". The proof is in the pudding though, and I reckon that most people would be able to:

1. Grasp what they're supposed to do
2. Understand what's happening
3. Understand where it's happening

When we move to the land of Kinect hacks and away from the purpose built environment it was designed for, we lose 1, 2, and 3 for many people. Most of the hacks, be it the Shadow Puppets or the Optical Camouflage, are at proof of concept stage. They're fun and are a nice example of how you can "leave the box" and think outside of it. I haven't yet seen any hacks that are beyond proof of concept or that are genuinely useful. There are many reasons for this, but mainly, the technology is very new and so is the whole idea of hacking it. I reckon more interesting things will emerge later down the line.

What I'm finding interesting though is that once you remove the context (the Xbox), you are left with a lot of work to do for the non-geek to grasp what's going on. I ran a creative technology workshop recently with a group of business people. We looked at Kinect specifically, and after spending time understanding the technology, we looked at a series of hacks too. They were all amazed, and in awe like little kids at a candy store. I then asked them to get into small groups and come up with some ideas for hacks of their own. Bearing in mind that none of them were technical people, I was hoping to get some interesting insight into usage. Interestingly, what I found is that they struggled to come up with anything new. Having run quite a lot of these workshops before, with the same kinds of people, I was puzzled. Normally, they always come up with a few things I would never have thought of. More interestingly...they (all sort of) presented the same idea, and none of them noticed. Mostly thoughts revolved around using it to do something that is already possible without Kinect but with it. Seeing we are talking about a technology that allows you to speak to the computer and interact physically with a virtual environment, I was stunned. When the technology is then safely placed back into its Xbox environment, there is a lot less struggle with it as a technology or even as an idea.

MSFT are already investigating what comes after Kinect:

For a long time we investigated (or obsessed about) putting ourselves into a virtual world. We did this with avatars, through games, through virtual worlds and so on. Now, we've flipped it on its head and we're more interested in integrating the virtual into the real world. This changes the whole user experience and I don't think we've given it a lot of thought as yet. I'd be interested in hearing about any projects or testing happening in relation to this.

In the meantime, check out this very cool video, taking us further down those futuristic paths: