10 principles of Design for software

Dieter Rams was chief of design at Braun (1951-1995), where he emerged as one of the most influential industrial designers that has ever lived.  His legacy is of immense importance to us all. In the 80's, as consumerism went wild, he felt unhappy with the way things were going and penned his "10 principles of design", sometimes also called "The ten commandments". This sound advice resonates with me, and applies even in the world of software, where the level of complexity is typically very high. It takes a lot of practice and patience to be able to mentally abstract out all the angry noise out and provide a quiet and balanced design. Dieter Rams also penned my first and foremost rule of thumb: "If you can do it with less, do it". As he says here, design is not all about "making it pretty": “To use design to impress, to polish things up, to make them chic, is no design at all. This is packaging. When we concentrate on the essential elements in design, when we omit all superfluous elements, we find forms become: quiet, comfortable, understandable and, most importantly, long lasting.”

Here are the Ten principles, re-framed for the software industry:

 1. Good design is innovative

This about not blindly using pattern libraries to address interaction problems, or with no forethought, going ahead and doing something you have done a thousand times before. Even if it is "just another web form" for example, and that you have made thousands like it before, what is it you have become blind to? What is it that you can change? Is there a better way? Does there even need to be a form? Every time you approach a piece of work, "empty your cup", and try and see it with beginners eyes.

2. Good design makes a product useful

Question whether the features you are designing are really needed, and ask users even if you think you're sure. If you make features that nobody uses, its wasteful and already bad design in itself. The Standish Group’s statistic is that 45% of features in software go unused. It's your job as an experience designer to ensure that the user gets what they need, not what they think they need and not what anyone else thinks they need. This is why it's good to do prototype testing, and also role-playing.  Role-playing will enable you to work out what the interaction users want to have with the system is, better than asking them what features they want. The same goes for unnecessary images, links, text, screens, clicks, cognitive load...keep it simple and balanced. Do away with anything that detracts from the original user intention.

On another note, before embarking on building a product or a service, system or process, ensure that it is going to be used, that there is a genuine need for it. Please don't make the software version of one of these.

3. Good design is aesthetic

This sounds like a no-brainer, but there is a lot of awful looking software out there, some that I am sure you use quite often as well. It's one thing for it to be functional, useful and that it "does what it says on the box" but you're not selling a can of beans here. This is where you really need to have someone who understands what makes a good design also visually pleasing. Different aesthetic directions will work for different cultures, sub-cultures, demographics and so on. The visual designer does not make something that s/he wants to see, but rather something that will work for the audience and the brand. S/he will use their expertise and experience to ensure that it looks good as well.

Don't underestimate this part, and over-simplify it. If you have ever had to make presentation slides, you will know how time consuming the visual design can be. It requires a really creative thinker and an accomplished expert to make an excellent job of this. Beauty is in the execution.

4. Good design makes a product understandable

The software you make should be self-explanatory for users. Help text and lists of FAQ's are a poor substitute for good design. It should be obvious to the user what it is they need to do, and what the software will do for them. That conversation between human and software must be smooth and simple. Continue to refine the design until users can easily and quickly achieve their goal...without frowning or looking worried.

5. Good design is unobtrusive

Your software is not a work of art. Its function is not to provoke a reaction in anyone. It should fulfill its purpose and do so elegantly, without arrogance and without trying hard to be noticed and loved. It should be a comfortable enabler for people. Dieter Rams defines "unobtrusive" as "both neutral and restrained, to leave room for the user’s self-expression". The same is true for design in software. Imagine that the software is telling a story, and allow the user to write the ending.

6. Good design is honest

Always deliver on your promises to the people using your software, even if they are implied. Software needs transparency to gain trust from the people using it, and to gain their loyalty. We need to be clear about what we're doing with their information, with their money, with their actions, with their social networks...and be sure that we've communicated that really well. We also need to be transparent about what our software can and cannot do.

7. Good design is long-lasting

Dieter Rams said that "It avoids being fashionable and therefore never appears antiquated". In the world of software, there is a lot of waste. An Agile philosophy, with well integrated experience design practices will ensure that the right thing is delivered, and that it fundamentally lasts. It will go through iterations and then more iterations and really never be finished, as software moves and morphs with needs and changing technologies. We should ensure that our decisions are not based on what's hot, but what's needed and what is best for the business and the people who will end up using  our software.

8. Good design is thorough, down to the last detail

I said in my "Experience design manifesto" that I would "Sweat the details so that you don"t have to". A great execution of an idea is fundamental to it succeeding. Every detail of the experience design needs to be thought through, so that we can ensure that it's not clumsy to use. The information architecture needs time and testing to get right, interactions that seem like a good idea in your head don't play out as planned, and not everyone uses the same language as you do. Testing with enough users will allow you to hunt for the details, as will running an "unfocus group" with users from polar extremes of the spectrum.

9. Good design is environmentally-friendly

Let us please put a stop to all those horrible websites that litter the web, software that gets left unused or abandoned by those it was intended for, and the software that causes pain, anger, and sadness in people. Software needs to be human-centered to be environmentally friendly, because its environment is people's lives.

10. Good design is as little design as possible

Good experience design is about taking things away not adding things in. Can you design fewer steps in the process, fewer clicks, fewer screen reloads, fewer minutes waiting, fewer distractions on the screen...Can you create an experience that is less hassle and less painful than any other? We often talk about making experience design more enjoyable, or delightful or something else. Really I think that we should not be "making" but "unmaking" the experience, at least to begin with. What is the most direct path for a person? If that path involves being delighted that I can browse shoes or that I can quickly pay for something, then that should be the focus. Anything that distracts from it should be taken away. Each part of the software must not overload me with choices but point me to where I need to be. In order to do great experience design, you have to be able to synthesize all of the information that you have about about it, and distill it down to the crux of the thing. Then simplicity emerges.

A couple more quotes from Dieter Rams for your pleasure:

"A designer who wants to achieve good design must not regard himself as an artist who, according to taste and aesthetics, is merely dressing-up products with a last minute garment. The designer must be the gestaltingenieur or creative engineer. They synthesise the completed product from the various elements that make up its design. Their work is largely rational, meaning that aesthetic decisions are justified by an understanding of the product’s purpose.”

"I hate everything that is driven by fashion. From the beginning it was hating the sixties American way of styling. Especially the cars. They changed their styling every two years to sell more. Which has nothing to do with good design".

“Good design is innovative. It does not copy existing product forms, nor does it produce any kind of novelty for the sake of it. The essence of innovation must be clearly seen in all functions of a product.”

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

5 common "lean" misconceptions

Eric Ries wrote "The Lean Start-up", a book that has hugely inspired people from all sorts of industries and backgrounds. His Lean Start-up methodology is pretty much world famous by now. "Do one important thing: make better, faster business decisions. Vastly better, faster business decisions. Bringing principles from lean manufacturing and agile development to the process of innovation, the Lean Start-up helps companies succeed in a business landscape riddled with risk." (Eric Ries)

There are however a lot of things that get misunderstood, so I decided to list here the top 5 that I encounter most commonly (not necessarily at work, but also with friends).

1. "Lean" means "cheap"

Lean is about reducing waste and being super efficient, it has nothing to do with your budget. If you have $50 to invest in your new product, then it might not be enough depending on what the problem is that you're trying to solve. Then again $500,000 might not be enough either! This is far more about learning quickly what works and what fails. If you hire a cheaper, inexperienced team to build your MVP, it will cost you more later down the road. It might be cheaper in the long run to hire in a very experienced, much more expensive team to do the work. You're more likely to get something you can test much faster with them, plus it'll be high quality and this is important.

2. Lean is only for software start-ups

You can apply this methodology to any industry and any size of company. The bigger your company is and the more history it has, the more you are going to have to think about change management of course. People love a fresh idea and usually get very excited about thinking about a new way of working. What tends to happen is when the reality of it sets in, there can be resistance. This is only natural, change is described as the root of all human suffering after all. Don't underestimate the change that your organisation may have to go through. Factor that in early and use lean to figure out a way to proceed.

3. Minimum viable product (MVP) is quick and dirty

It is simply a product with the minimum features required for it to function as intended. It needs to provide enough value to users/customers, and your code needs to be good enough to maintain and build upon. Otherwise you are setting yourself up for problems and high costs later on (i.e. you'll need to rebuild the entire codebase.) You are not going to be able to test hypothesis in a timely manner if it takes 2 weeks to make a change. This will slow down the whole process and before you know it you'll be in an unhappy place. You are still going to need to think about branding, SEO, communications and all that stuff too, or whatever is applicable to your solution. It is not a case of "build something crappy and they will come". Think high-quality and high-discipline, but only on the minimum features required for you need to test your idea out. There's a whole bunch of stuff that will still need to get done that has nothing to do with features too.

4. "Customer Development" is just feedback

If you are going to use Lean, then you need to get on top of proper user testing methodologies, and apply them effectively. You can't invite 3 people in every week and just ask them what they think. You have to test by seeing how they interact with the solution. You will also need verbal and emotive feedback. There are a lot of ways to do this well. Throwing down some poorly thought through questions in an email and calling it a survey is not going to fly. The point here is not always to validate your hypothesis, but also to find out what you don't know. A user interview is not a chat. You need to plan and prepare for this so that you can rely on the information that you are getting out of it.  A focus group is not usually the most effective way of getting information. Get users in regularly to work with the team on what a good solution looks like from the beginning, and vary the types of users you invite. See extreme users as well as those who fall in the middle and those who don't see the point in your invention. Don't spend all your time talking, get them to draw, prototype, role play the solution and watch and listen attentively. If you have never done this, either step onto that learning curve or hire someone in who knows how to do this.

N.B: It's also not just about what the user wants, but also about what's viable financially for you, and what's feasible technically too.

5. "pivot" means throw the baby out with the bathwater

You need to validate your idea properly and accurately. You should do everything you can to check your assumptions, and if they prove to be wrong, you need to drop the bits that are not working…not the whole thing. If you decide to abandon the entire project and start an entirely different one…that's not a pivot. It may be exactly what you need to do, but it's  new start. An important bi-product of lean efforts is learnings. Make sure that you use your new knowledge effectively, this is valuable stuff. Ensure that your analytics are set up properly before using them to make business decisions, and ensure that you are not misunderstanding what they are showing you. As a rule of thumb, I think that you should always make business decisions based on at least 2 different sources of data (e.g. your web analytics and also real user testing).

6. Bonus number 6: "Just start and we'll figure it out later"

A lot of people are eager to jump in and start laying down code or drawing up  solution straight away. In some cases there's nothing wrong with this (in fact in one case it was the only right thing to do), but for most of those I have witnessed, it was not the right thing to do at all. You need to make sure that you understand the problem space as much as possible before investing further. Resist coming up with solutions until you have thoroughly understood the entire problem. This is going to either save you time and effort, lead to an even better idea, or/and save you a lot of unnecessary expenditure.

What you are trying to understand is whether the problem is worth fixing or not. It takes as much time to solve a bad problem as it does a good one. Don't waste your time.

Take the pain out of failing

A lot of us have the joy of working in Agile environments and have all read, heard and learned that you should "Fail fast and often". The idea is basically that if something isn't going to work, it's better to find out as soon as possible, and learn as much as we can from it so that we can move on and focus our energy on something that will work. It doesn't mean that we set ourselves up for failure, quite the contrary, we try to do everything we can to ensure success. The problem is that if you are working in an innovative space, or say, in a well defined space that you're looking to disrupt, it's hard to guarantee success off the bat. What's interesting to me, is that we don't like to fail. I have yet to meet someone who really relished in this. I know a lot of people who can see the value in failing, and are comfortable with the fact that it will happen and that we will learn good stuff from it. I don't see anyone celebrating when it does though. People swear, wring their hands, shake their heads, some even cry. But  I think we should celebrate. That we didn't get to where we intended to be is not important. We may well have been striving for the wrong things, or looking at it the wrong way. It was not going to work and we found out early. Surely this is good news.

The idea I think, is to focus on going forwards, without being attached to the outcome. The pain, the anger, the fear, the emotions that are so often felt during failure are those that come from that.

If we can be excited about the journey, about what we are actually doing rather than where we are expecting to end up, then we can really let go of the attachment to the outcome and enjoy this unique process. The beauty in this is that when we do succeed, the outcome is a true celebration rather than an expected situation that we take for granted.

Designers, be generous.

Many of us are consultants, work for agencies, or are freelancers which means that we get to meet a lot of different clients and work on a wide range of different projects. All of these projects come with their share of opportunities, challenges, laughs and lows. Some teams you'll get on with better than with others, and some will naturally gel straight away, whilst others will take effort and time. There will be projects that don't go your way, and some that allow you to over-deliver and out-do yourself. There's no telling what combination of circumstances you are going to face on your new project, so come with an open mind and an open heart. It's not about you

Some clients aren't going to understand why you are pushing for a particular outcome, or why you are unhappy about a change in direction, heck, some won't even understand why you're even on the team. Who needs an experience/service/product designer anyway? Isn't your job just to make things pretty? Why are you talking about information architecture and on-boarding processes? You won't always agree with the decisions they make, despite all your efforts to explain and your polished presentations. You might want to wring your head in your hands sometimes, or cry out in pain as your design is pulled apart and demolished irrationally, pixel by pixel. Your best efforts at delivering the perfect experience and the most compelling design is thwarted before it even has a chance to be explained. But this isn't about you or what you want.

Give them what they need

Don't become so demoralised by these experiences that you stop doing your best work. Be accustomed to change. Give them what they need to progress on to the next level of understanding, to the next experience that drives them towards a direction or a goal, to the next rung of the ladder for them. It isn't all about you and your desire to create a flawless, beautiful and meaningful piece of work. It's about educating, explaining tirelessly, trying a new tack, finding the sweet spot where the client, the users, your team and you can work well. It's about doing what's right, right now, and sometimes, shock horror, they are afraid of their users, afraid of showing their product, or so convinced that they know what their users want, that you will largely be ignored. We have an interesting job, which requires us to play a game of balances. Balancing what the client is ready for,what the users need and what your team can deliver. Sometimes these things are completely at odds with each other.

Be cool

Be kind, be open-hearted, be cool, be patient, be friendly and be generous. Be generous with your ideas, with your time, with your knowledge, with your smiles. Tell them what they're doing right and not always what they're doing wrong. What's wrong is always available, so ask yourself what's right and start from there. Tell them how much you appreciate working with them and having the opportunity to be part of their work. Remember that they may be under a lot of stress, and your support will earn you a reputation for being willing to listen and help, for being constructive. In return, you will be listened to and you will earn their trust.

Be passionate

Still do your work with energy and vigor. Challenge the status quo and the people on your team. Push for change and improvement. Don't be afraid to suggest something wild that you think might work, and be honest when you they ask you if you're sure. Say "of course not, but here's why we should try". Look for ways to make things happen. Keep it fresh. There's no better project or client than the one you're with right now. Find what stirs them and be a part of it. Initiate. Pick up the slack. Turn things around. Keep trying and have the wisdom and compassion to stop pushing when it becomes unproductive for them, your team and yourself. In that situation stop moving and listen.

Tread carefully

This is their dream, their baby, their investment. Respect their capabilities, their desires, their weaknesses and discover their untapped genius. Be the generous designer. It's nice to be important, but it's more important to be nice.

100 ways to a better life

I make a list like this every so often, after I have been reminded of the sheer joy that is simply living. They help me when my mind is obscured by my own thoughts, or basically when I am in the way of life itself and need to step aside. The first part is being aware of when that is, and the second thing is to know how to step aside. I usually keep these in my trusty moleskin, but I decided to share this one. Maybe you can make your own and share it with the world too. I particularly loved David Good's one, it has a lot of heart. Here's mine: 1. Be the first to smile

2. Learn the Hula and share it with others

3. Greet strangers like you greet friends

4. Eat honey out of the jar with your fingers

5. Practice Yoga every day

6. Teach Yoga to those who ask

7. Exhale all the way out often

8. Chant a little every day, it's good for warming the heart

9. Sometimes drop the chanting and sing a little instead

10. Savour food

11. Name at least 5 things every day that you are grateful for

12. Laugh openly

13. Don't be afraid to touch people

14. Really enjoy this moment, the now

15. Always do the right thing

16. Take care of your feet and hands

17. Surf at every opportunity

18. Send postcards, even if you're home

19. Draw what you see with abandon

20. Attentively listen when others are speaking

21. Take regular walks outside

22. When you wash your hands, take the time to enjoy the water and the soap

23. Visit art exhibitions and observe how they make you feel

24. Always volunteer for public speaking when it's about things you love

25. Visit the fine line between fear and excitement regularly

26. Make a new friend

27. Make someone feel good every day

28. Be generous with your compliments

29. Don't judge, even if you feel judged

30. Forgive, forgive, forgive again

31. Practice non-attachment to people, objects, thoughts, feelings...

32. Be kind to those suffering (everyone)

33. Run barefoot in the grass or in the sand

34. Learn something from everyone

35. Never be too busy for a kiss and a cuddle

36. Massage others (when appropriate!)

37. Question everything but never shoot the messenger

38. Read inspiring stories and share them

39. Learn to cook something new

40. Keep your secrets

41. Not only respect, but also honour others

42. Share all your good stuff

43. Surrender - the world does not rest on your shoulders, you are the dirt of the earth :)

44. Experience nature as much as possible

45. Pay for someone else once in a while

50. Listen to music from all over the world

51. Persist

52. Don't be afraid to be different

53. Don't try to be different

54. Burn incense every day

55. Spend time with children

56. Spend time with elderly people

57. Say "no" enough

58. Say "yes" enough

59. Get good headphones and listen to music while watching sunsets and sunrises

60. Yes...get up early so you have time to enjoy the start of the day

61. Don't hide your vulnerability, it's what connects you to others

62. Read the Yoga Sutra. Read it again

63. Pick your favourite fruit and describe it in as many ways as you can

64. Close your eyes and rely on your other senses

65. Don't argue with aggressive people, walk away

66. Be prepared to change your mind

67. Paint your toes in a colour that makes you smile

68. Celebrate the successes of others

69. Sleep early

70. Grow things from seeds

71. Be colourful

72. Wear comfortable shoes

73. Don't be afraid to get wet, walk in the rain, paddle in the sea

74. Enjoy your guilty pleasures, but don't be addicted to them

75. Don't buy stuff you don't need, you're stealing from yourself

76. Sponsor a child

77. Sing or whistle with the birds

78. Have a reusable water bottle on you

79. If you are a Yogi, practice all 8 limbs, no just Asana

80. Speak to those no one speaks to

81. Meet your neighbours

82. Ride a bike or a skateboard everywhere

83. Refuse to rush

84. Sit on the floor every day

85. Buy a tube of soap bubbles and blow some

86. Gift your favourite book to someone every so often

87. Give the senses a rest and turn off the idevices at home

88. Take a class in something new and random

89. Meditate or try to

90. Moisturize

91. Doodle

92. Donate all the stuff you don't use or wear

93. Use an eye bag every so often and relax

94. Nurture your friendships

95. Call home regularly

96. Buy flowers for someone every now and again

97. Write a poem

98. Feel your breath in your body

99. Do things without attachment to the outcome

100. Love <3

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")

Ways to keep your smart team innovative

  Is this you?

I've seen teams start out by making big long lists of tasks and deliverables at the beginning of a project. This assumes that they know exactly what the product is going to end up being. I think that this kind of way of thinking goes entirely against a culture of creativity and innovation, and of the Agile philosophy. By deciding on all of the tasks up-front and by setting up an infrastructure for the team to work in (process, tools, tracking, tickets...), we actually restrict the potential for innovation.

What it takes to innovate:

Innovation requires serendipity and creativity. If we impose a tonne of rules and processes, we throttle both. Before deciding on what the product is and how to get there, you should start with a creative brief and well thought out elevator pitch, that allow the team to think for themselves, and have focus without being dictated to. If you have a team of very smart people, they will most likely feel disengaged if you give them requirements and impose goals and a path to follow. Each of them come with a wealth of expertise and experience that should be allowed to flow through the product, fully. To do this effectively and to set yourself up for the highest likelihood of immense success, you need to get comfortable with the gaping voids that inevitably exist in projects, and in fact allow them to be much positively palpable. When you set up processes and tools, you are filling up the void, masking it with man-made certainty that doesn't really exist. If you are after a cog for your machine, then this will work fine, but if you are after a whole new dream machine, then this won't do. Drop the rituals and face the discomfort of the unknown square in the face. If you are feeling uncomfortable and so is your team, then you are in a good place. If chaos ensues...then this is extremely good news.

The voids on a project are like unchartered territory, which can lead to great discoveries. There were those that thought that the earth was flat and there were those that wanted to check. The latter were forced to innovate simply to make the trip possible. They had a starting point and went from there. This is often how the most inspiring projects are started. Even the most mundane projects can be fertile ground for innovation if you allow for the circumstances to be exist.

A quick checklist:

• Make sure your team has mastery around the work you are planning to do (everyone)
• Only set up enough structure around the team to allow them to gain focus and begin to be productive
• Don't use Agile tools and methods to minimise uncertainty and discomfort
• Trust your smart team to be in charge and self-organise
• Give a creative brief to provide focus
• Impose frequent playtime on the team and make sure they stay fit, rested and healthy
• Be clear about constraints (budget, time, resources...) - constraints are conductive to innovation
• Be prepared to be surprised and to bend your mind into different shapes
• Don't get attached to your idea of the product - the team is going to shape that
• Remember, there is no such thing as an end-product - there is never an end.
• Be brave

Stick these up to keep you clear:

"When all think alike, then no one is thinking." — Walter Lippman

"It's easy to come up with new ideas; the hard part is letting go of what worked for you two years ago, but will soon be out of date." — Roger von Oech

"The best way to have a good idea is to have a lot of ideas." — Dr. Linus Pauling

"We shall not cease from exploration, and at the end of all our exploring will be to arrive where we started and know the place for the first time." — T. S. Eliot

"The essential part of creativity is not being afraid to fail." — Edwin H. Land

"The achievement of excellence can only occur if the organization promotes a culture of creative dissatisfaction." — Lawrence Miller

"Every act of creation is first of all an act of destruction." — Picasso

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." — Howard Aiken

"Creativity is thinking up new things. Innovation is doing new things." — Theodore Levitt

Happy doing...

SxSW workshop: Agile Experience Design

As some of you know, Cathie Hagan, Megan Cook and I recently ran a workshop at SxSW entitled: "AXD: Agile Experience Design". This was a good mix of skills, as Cathie is from the BA practice and Megan is a bit of a hybrid between BA and XD.

What we did:

We were allocated a 60min slot to run a workshop on Agile Experience design. There was a diverse audience of designers, developers, managers and company owners. Some were familiar with Agile, many were not. We wanted to teach some fundamental principles of design in Agile teams and to allow people to experience it for themselves.We designed the "Play Doh Zoo" game (inspired by the Lean Lego game).

We split people into teams as they came into the ballroom and then those teams were split into construction workers and designer/planners. An extra group represented the customers. We prepared packs for each team full of play doh, pipe cleaners, pop sticks, tape and more tools. We gave them foam boards to build their zoo on. We used whistles to signal the end of iterations, and we led them through a retro highlighting the learnings we wanted them to take away. We will post more information about how to run this game soon.

Roy closed our session with a stirring and inspiring speech and you can see his notes here. It definitely inspired the crowd, and helped people see that we are much more than just another software consultancy.

How it was received:

As the whole ballroom descended into chaos, I was quite sure that we had pulled it off. A client tapped me on the shoulder and told me with a wide grin, that this is exactly how it feels when we come into their workplaces. People were running around, fully engaged in the game, and shouting enthusiastically at each other.

Lots of people came up to us at the end and said that they really enjoyed themselves, and that they learned a lot. It's clear that it would have been great to be able to do an hour Q&A session after the game, as we spent at least that long answering questions. A couple of people felt that we didn't give time to answer their questions and some were disappointed because they thought this was a panel, although it was clearly listed as a workshop. You can't please everyone, and we take this on as feedback that next time it would be good to also run a panel at SxSW.

How we would do things in an ideal world (briefly):

Agile is about continuously evolving your product, this is BOTH delivery and design. You need to build what you can with what you know. That is, start with some of the known areas, use your design patterns. For instance, registration forms are a well know space use the best practice here, get the team working and spend your research time and energy in the truly innovative areas of your product (hint this should happen in parallel).The key is getting the product out as soon as possible so you can validate that what you are actually building (rather than conceiving) is the right direction.

The benefits of this approach are many. Firstly you can validate your direction. Secondly your client (product owner) is happy because they achieve ROI earlier, and they can really see the product evolving, rather than less engaging documents they can play with the real thing. Finally your team will be happy as they will be able to start making them feel more confident that they can reach their deadlines and more engaged.

The other important point is to be collaborative while design. Not just with the business stakeholders either, make sure you can include your team. The developers will invariably have a deeper product knowledge than you and their fresh perspective may uncover fresh opportunities that would have never been thought of without their inclusion. Also collaborating is the easiest way to to get buy in, as the design becomes communal property rather than seen as something imposed.

For a good impression of what we did, take a look at Adam Kleinberg's excellent write-up.

Love your dragon

No death = No Life

No change = No transformation

"We must be willing to get rid of the life we have planned so as to have the life that is waiting for us" (J. Campbell)

Be willing to keep dying.

Follow your bliss.

The universe will open doors where there were only walls.

Love is what we're born with. Fear is what we learn.

Have courage.

Love your dragon.

(Notes from Finding Joe)

Creative briefs for developers

photo credit: erix!

If you want your development team to be autonomous, rapid and creative, then you need to ensure that they have the room to move so that can occur. Often teams are given a very tight brief, which leads to the group of smart people you hired taking time to convince you on an alternative solution, or actually just not being in a mindset which drives innovation and excellence. You'll get good functional software for sure, but getting what you asked for isn't always a blessing. If you want the best solution for the problem that you are hiring them for, don't go into solution mode just yet. Articulate your problem to them in a creative brief, which will allow you to inspire the team, and get the most form them.

What Steve Jobs did very well:

Luke Williams  (in his book Disrupt) tells the story of when Steve Jobs came to Frog design to brief them on the work he wanted them to do on the (then called) personal computer. They were expecting a fat document full of restrictions and "must's" and "must not's". But Steve came empty handed and instead asked the team to "Give me Bob Dylan songs". Steve Job's genius was really in how he briefed teams. Giving enough context that they are on the right path, but expressing his need in a way that the teams could get a good sense of where his head was at with the work at hand.

Give a creative brief to the whole team, not just the designers:

Brilliant developers should be briefed in the very same way. I say "brilliant" because they are the ones that really benefit from creative briefs. If they are amazing technically, and that they positively become the code when they work, then you should trust these people to know what to do. If you don't have those kinds of people, you might be asking for trouble by leaving the brief open like that.

Really great thinkers will appreciate your open brief and will do awesome work for you. They are so good technically that they can work fast and produce high quality work. This does not mean that they should be treated like "code monkeys" with a designer in the mix to ensure that something creative results from the effort. You put the designer in a tough place with a lot of responsibility for the innovative and "fun" parts, and leave a very talented group of innovators to just build and not think creatively. Put the creative brief to the whole team, and you will get good results.

Pitch your idea to yourself first:

The creative brief forces you to listen to your idea yourself first. If you are struggling to write it out in a succinct and simple way, then you likely have more thinking to do before briefing a team to work on it. You can get help with this, there are a whole load of methods designed to get this out of you. Check out the book Thinkertoys for more information on these. If you have written your brief out and it doesn't inspire you or leaves you flat, then you;re also not ready to brief the team. Go and think some more until it's clear to you what exactly you are looking for the team to do. They don't need instructions or a checklist, they need a brief. They probably know more about technicalities and design and how to incorporate the two than you do, or you wouldn't need to hire them. Give them your great idea, your vision, or even your gut feeling.

The Brief:

You should put a brief together that you are comfortable with but it should be:

- Creative: resulting from originality of thought - Brief: short

Call it an "Idea sheet" or a "What I want" sheet...whatever you want to call it, and then decide on the best way to communicate your vision to your team. There are thousands of examples of creative briefs on the Internet, so a good scour might be in order, but this is the one I have used recently:

1 - Name your idea: (one idea per brief)

2 - Elevator pitch: (describe your idea)

"The_________________ is a __________________ For_____________________ who need ______________, that allows _________________unlike_____________.

3 - End users: (Say more about who it's for)

4 - Why they should care: (What is going to make end user want this solution)

5 - Why this solution will answer their needs: (make sure you are succinct here)

6 - Draw your idea out: (You don't have to draw well, but you should be able to represent it simply either with stick people or a quick diagram)

Your brief should spark enthusiasm, excitement, loud conversations, passionate disagreements and wonderfully happy teams. You will also be very happy because you will probably have at least a few  unexpected twists and a really awesome product. The most important thing for you to do is to trust them. Once you've hired them, you feel comfortable enough to let them make decisions and mistakes too. Innovative products usually come from a place of great heart, chaos and a few counts of failure. Let it happen quickly and you'll have a better result than you ever imagined possible.

Determining user internet experience level

photo credit: workshoppe Self-reported skills are typically very inaccurate. Inexperienced users tend to overestimate their skills (because they don't realise their own incompetence), and experienced users tend to underestimate their skill level (they are aware of the edges of their knowledge and all the things that remain to be learnt). It is important to realise that the only way to really gage the skill level of someone is to directly test that particular skill. If you're going to have a decent sample size, and ship a product in a reasonable amount of time, then that's not going to be an option for you. If a survey is your tool of choice and understanding internet or computer skill level is important to you, then there are a few tricks that you can use. Make sure you have a decent sample size and that your survey leads to positive action.

General survey creation tips:

Annette Franz Gleneicki from CX Journey has a great post on how to put together a good survey. I recommend giving that a read before you start. You need to be pretty clear on the goals of your survey and what you would like to be able to action as a result of it. Ensure that you send it out to the right cross-section of your target demographic, and make it short and sweet. I recommend using post-it notes to craft your survey, writing a question on each one and the answer method you are choosing along with it on a different coloured post-it note (checkboxes, star rating,...). This will allow for a few things to happen:

- You have clarity over your work - Your team have visibility of your work - Stakeholders can come and give their opinion as well - It is easily modified

As the team designer, you are stil part of the team and should get the team's advice and feedback on your work as much as possible. Even if what you are doing is something you have done thousands of times, and that you are very confident. Including the team and the stakeholders allows them to also own this and have a stake in it, as well as help you refine what it is they would like to get from your work. Most importantly: it's fun.

Determining user internet usage experience:

This is not straightforward as people generally have a hard time describing accurately how good or bad they are at something. To be fair, it is a very subjective thing to ask, because it requires you to compare yourself to others. If you're going to be objective about it, the only answer is: I am what I am. That is not however going to help you gage your end-user savviness with the internet or technology.

These types of skills can be split into 4 categories:

- operational: using the navigation bar, bookmarking websites, changing browser preferences,... - formal: not becoming confused or disoriented whilst navigating the web - information: locating the correct information - strategic:making decisions around how to reach an end goal

Alexander Van Deursen has carried out a lot of research around skill levels in internet user, and he found that "age is mainly related to operational and formal problems. Though the number of operational and formal individual Internet skill related problems is highest for the oldest age group, surprisingly, they do not experience more individual information and strategic skill related problems."

Before you even start constructing your survey, make sure that you and your team and stakeholders have an agreed definition of "internet skills" or "Technology skills" and what you consider to be "expert" and "novice" skill levels. If you don't do this, it will difficult to separate the wheat from the chaff when you have the results in. Once you've done that, make sure you have a decent pool of users to target and that you are going to get answers in a way that allows you to draw insights quickly. For example, if you ask for a lot of narrative from users and you get 500 answers, you're going to spend a long time reading.

To get a good idea, you are going to have to ask them a few questions in a particular way and order, for example:

- How internet savvy are you on a scale of 1-10? - Which online activities do you carry out daily? - What device(s) do you use to go online? - What are your 3 favourite apps? - If you were in charge of x, what would you change?

Your whole survey should be centered around this one question "How internet savvy are you?".

What you will see with these types of questions is someone rating themselves as a 10, who only uses email once a day and has never shopped online. This is useful for several reasons. It tells you how your users view themselves, or how they would like to be viewed. It also allows you to understand what interfaces and interaction patterns they are habitually exposed to, and how much change aversion you might have to contend with. You'll also get an idea about how comfortable they are with internet-based technologies: if they like to watch videos and movies online and barely watch any tv as a result, then you have a different kind of user than one that says they only watch tv. The nuances will be interesting.

That said...

If you don't consider it primordial to have the answer to that question before you start, you can of course use common interaction patterns to design your website/software. Those used in the most popular applications such as email, Facebook, Google, YouTube, Wikipedia, Amazon...those used by your traget group should help you to design something that sits reasonably well with them. You can simply ask what their most visited websites are, for example, and go from there. Build something that behaves and operates the same way as the other interfaces and tools that they are used to and set up some reliable and insightful analytics. Then go live and see what happens. Be ready to intervene rapidly with a very competent team if something looks like it's going "a over t". We often learn more when what we are making is in its natural habitat. Get it to that stage asap, regardless of which approach you decide to take.

The Agile experience designer's kit

The Agile experience designer's kit
by Marie-Claire Dean

See all 16 items

What is an "experience designer"?

Here is my brief attempt at describing what it is some of us do. Emphasis has been placed on simplicity of message.

Learn to listen

Listening is arguably the most important skill you can have as an experience designer. Very very few of us know how to listen to others. It is not a skill that is taught very well at schools in general, or in universities. Most of us don't even know what it means to listen, which means that we don't even know where to begin to learn this precious and underrated skill. The Merriam-Webster dictionary defines "listening" as:

1: to pay attention to sound

2: to hear something with thoughtful attention

Many of you, I suspect, would say that the most relevant to experience designers is #2, however this is part of our problem. Before we can listen to somebody with thoughtful attention, we have to learn to pay attention to sound.  This is not as easy as it first appears, so give it a try:

1- Sit comfortably 2- Close your eyes (it will be easier if you withdraw the other senses) 3- Listen to the sounds that are very very far away 4- Listen to the sounds that are very close to you 5- Now listen to the sounds that are somewhere in between the previous two

You should be able to comfortably, with passive alertness, do this exercise for at least 20minutes without:

- Fidgeting - Your mind wandering & losing concentration - Hearing the sound of your own voice inside your head - Having a conversation with yourself - Waiting for this exercise to end - Labeling all of the sounds individually - Effort

When you do any of these things, you cease to listen.

If you cannot focus on the noises around you with your eyes closed, whilst sitting comfortably, without your mind getting in the way, then it will be very very difficult for you to be able to really listen to somebody else talking to you, especially if you are on the phone in a busy train station, for example.

When we are listening to someone else speaking, we are not waiting for our turn to speak. Harder still, we are not listening to our inner monologue whilst they are talking. If you cannot listen to them without your inner monologue going off all the time, then all you hear are your own desires, you project your own ideas onto their words, and you never really listen to them, or even hear them.

Robert McCloskey famously said:

“I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”

Listening to somebody means that you are intently focused on that person and what they are communicating. You not only hear the sound of their voice, understand the words that are coming out of their mouth, but also see their body language, their facial expressions, and develop an understanding of what they are trying to communicate, without warping their communication with what your mind thinks they are saying. It is to listen without judgement, and without commentary, to what another person is saying.

Krishnamurti said that:

"To listen, there must be an inward quietness, a freedom from the strain of acquiring, a relaxed attention. This alert yet passive state is able to hear what is beyond the verbal conclusion.  Words confuse; they are only outward means of communication; but to communicate beyond the noise of words, there must be in listening an inner passivity."

This skill is very difficult to master, and I wager that 99% of us at least (myself included) are incapable of truly listening to someone for any substantial length of time. It is certainly worth our while to get better at this, because it not only affects our work, but also every other aspect of our lives. As experience designers, we often listen to the end user, waiting to acquire that nugget of information that will help us to improve our work. When we have this attitude to listening, we are in danger of only hearing what we want to hear.

Doing the listening to sounds exercise (that I have described above), every day for at least 10mins at a time, really can help you to improve your listening skills. It is a meditation exercise primarily, as it requires your mind to be intently focused on one thing: the sounds around you and nothing else. It helps develop concentration also, and is a very peaceful thing to do. Whatever the sounds that you hear: police sirens, doors slamming, water pipes bubbling, cars humming in the distance, the washing machine churning, or even your phone going off...they are all just sounds. They're not calls to action. If you can listen to all of the sounds around you, you are no longer confining your mind to one channel. We become open and aware of everything around us. Developing this awareness itself leads to great insight.

Another important point is that when we really listen to someone, we give them the space they need, to be. Holding this space for them is a deeply compassionate and powerful thing to do.

Krishnamurti also said:

"You will find that the more you listen to everything, the greater is the silence, and that silence is not broken by noise. It is only when you are resisting something, when you are putting up a barrier between yourself and that to which you do not want to listen - it is only then that there is a struggle."

If you cannot truly listen, then all you hear is yourself.

Evelyn Glennie shows how to listen in this TED talk, enjoy - I loved this.

My retrospective: 2011

photo credit: danicuki

I have had one awesome year. It's aways fun to do a retrospective when it has been a highly successful one, full of big achievements and good surprises. It's always a little harder to retrospect about a tough one, or one where there have been more challenges than achievements. The thing is that I had to go through quite a string of years like that to plant the seeds to set me up for the success that this year has brought. Some who know me less well think that it's all seamless, but you know, as it is said "All the so-called "secrets of success" will not work unless you do."

There is of course an element of luck, for want of a more specific word. I think it relates to the happy encounters with people who inspired me, changed me, taught me something (even those people who I didn't necessarily get on well with). There's also the fact that I was born in an environment conductive to the path I took, and that I had great educational opportunities, learning opportunities, access to computers, resources, books and a lot of things that many people are not lucky enough to have.

But you still have to take the bull by the horns, seize the day, seize opportunities when they show up, and make stuff happen. And then, you give back.

ThoughtWorks:

This year I made the best decision of my career and joined ThoughtWorks as an experience designer. It has been a very rewarding and worthwhile experience, where I learned a lot and have joined a family of like-minded people. It wouldn't be exaggerating to say that I feel like the context to who I am has just been added. I am working with energizing people who inspire me, help me develop into an even better experience designer, and never ask me to lower my bar. In fact, they suggest ways in which we might even raise it. I am surrounded by friends who are as passionate about software, people, our world and how we make a positive difference to it. I worked on social impact projects that are close to my heart, as well as on interesting problems for business clients. Some of those friendships run deep and change me. I am profoundly grateful to be part of this. It's a really special company.

Ph.D:

This was also the year that I finally finished my Ph.D and learnt the most wonderful thing in the world: that there is more to learn. I showed ingenuity and that I could have sophisticated ideas, working in complex environments, but above all, I showed tenacity. I had the ongoing support of Stephen Cox and Dan Smith, not to mention friends and family. A lot of people cheered me to the finish line and met me the other side with arms held wide. I learnt that as a scientist, my greatest asset was my creativity. I always felt a bit awkward amongst very "left brained" types, especially since there are typically so many in computer science. My approach was always a lot looser, more big picture, and very inventive. I found out that there is a place for me in this world too. Most importantly, I learnt what fed that creative spark: a big open heart, made so by years of dedicated Yoga practice.

Yoga teacher training:

I finished my Yoga teacher training course at the Yoga Institute. It's a year long course, with about as much work as I had to do for my Masters in Computer Science. I don't think I intended for it to be quite so transformational, but it certainly was. Just when you are in danger of thinking you know it all, you turn a corner and discover wide, wide open landscapes. Those moments are arresting and entirely beautiful. This is why I love science so much, and why I continue to be a devoted Yoga practitioner and now teacher. Those moments make you feel vulnerable, and they are brimming with opportunity. What I learnt from that place, I teach. The student-teacher relationship is sacred because of the appreciation I have for the teaching I have the honour of passing on.

Marriage:

This is also the year that I got married to a wonderful man that I have shared my life with for the past 12 years. The act of getting married can be lost in all the business of organising the meals, the invitations, the seating plan and flower arrangements, so we had none of those things. Our wedding day was about one thing: us. And as an extension of us, all the wonderful people who share our lives and inspire us. The commitment we made to each other makes me smile and feel enormously content. He is my husband.

Driving:

This was the year that I finally passed my driving test. It has been a running joke in my family, about how I seem to manage to absorb and master most things I set my mind to, but not driving. I found it really hard and still to this day don't understand why the car doesn't tell me what the speed limit is, why anyone needs to parallel park on a hill, or why other people don't indicate. Still, I have finally passed!

This year ends with family back home in Europe, and a year of new adventures begins. I cast a deep look of appreciation over my shoulder to those who are no longer on this journey, aware how much they touched my life. Then I swiftly look forwards and upwards, to the future, excited and full of plans.

It's been awesome. Thank you x

Are you really being innovative?

A lot of people talk about innovation, and a lot of people describe themselves as innovative. You probably know some too: "innovative problem solvers", "innovators", "innovation machines", "creative problem solvers", "Creative innovators"... but few people actually do innovate. What was your last innovative act? Was it an idea? If it was that's good, but realising that idea is just as important, and sometimes where your greatest chance at innovation lies. If all you have is a big list of ideas that never became reality...you're dreaming. Imagination is a really important part of innovation, so you are part of the way there, but innovation comes from making it happen. That's where it gets really interesting.

A few places to start:

Creativity is "the defeat of habit by originality". How often can you be original in your every day work? How often are you? Do you think you can be? Whether you fit kitchens or speak in court for a living, you can be innovative.

Here are a bunch of ways you can be invite innovation in:

- See the bigger picture; Step away, then step away some more...

- Flip the problems around to see different perspectives

- Stop colouring inside the lines

- Solve the problem rather than being right

- Deconstruct first, then construct

- Start with the desired effect/outcome (rather than the minimum requirements)

- Throw out the obvious

-  Rebel Intelligently against rules; those you set yourself and those imposed on you.

- Let go of what you know (and be ok with the uncertainty)

- Have vision, don't change things for the sake of change

- Hang a question mark on all of those things you take for granted

- Change lives, not companies, businesses, products or processes

- Have great ideas and execute them ; Get it done

- Challenge complacency around you and your own

- Demand innovation: "What if..."

- Disrupt habitual thought patterns

- Question why, when you do things the same way as last time

- Be curious and excited about challenges

- Try new things all the time

This will open your mind and your life in ways that you never imagined possible. It's easy to read this list, and easier to not attempt any of the things on it.

Treasure the limitations:

A lot of people talk about innovation in ways that seem elusive. It's almost as though you need to wait for the perfect alignment of the stars, the perfect team, the perfect conditions to be able to create something, or hatch an idea. Remember this quote when you start to think that way:

"Whom the gods wish to destroy, the give unlimited resources" (Twyla Tharp)

The more money you have in the bank, the more control you have, the more time you have, the more everything you have, the less you are likely to innovate. Innovation is borne out of limitations, out of need. Constraints mean that you have to be creative, that you have to find a solution. The best thing to have in the world if you want to innovate, is a good set of limitations. A chance to really dig at something and keep at it until you have it solved in a way that will surprise even you.

If it feels unsolvable, walk away. Mix it up and do something completely opposite to what you think you need to do. It'll change your perspective and cheer you up. When you least expect it, you'll see a few more ways to solve this one.

Persuasion and vulnerability:

If you're really innovating often, you're probably ok feeling vulnerable. When you're breaking new ground, you have a lot of people to convince before you can get your idea actually built or created. A lot of people will tell you it's too expensive, too insane, too "out-there", "nobody will like it". You need to be a master in persuasion and thick skinned at that. Howard Aiken rightly said:

“Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats.”

If lots of people are agreeing with you, and you're not getting enough pertinent questions, it should send your alarm bells ringing. Anything truly original looks ugly at first, so be sure to watch for that strange weird idea that doesn't sit quite right. That stands out. Give it some time, look at it again. Picasso knew how to do this really well. Something really original can be unsettling, Be sensitive to that.

Move in unfamiliar circles:

It's pretty tough to invent something completely novel. Sometimes great innovation comes from applying some method to a totally new field or combing a few things together that have never really been thought of in that way before. That's why it's so important to learn things outside of your field. That's why great innovators have passions in many fields. Steve Jobs loved art, Richard Feynman loved music, as did Einstein, Benjamin Franklin influenced physics, Isaac Newton, Isaac Asimov..where do I even start? Move in unfamiliar circles.

Leonardo DaVinci (another awesomely productive and curious mind) said:

“Although nature commences with reason and ends in experience it is necessary for us to do the opposite, that is to commence with experience and from this to proceed to investigate the reason.”

And that my friend, is a good place to begin and end :)

Displaying XD quality on physical story cards

It's not always easy to have an XD presence in a team, or to clients that are very new to the discipline. It's also not always easy to talk about XD when everyone around the boardroom table is unfamiliar with it. The other scenario is that everyone thinks they know everything about it already, because they either know about UI or have used an interface before. As we know a whole lot more comes into experience design other than GUI design, or making it all look pretty.

XD debt:

Additionally, ensuring that XD debt gets recovered at some point in time on your project is really important. Keeping track of that debt is really quite difficult. Basically, when a compromise is made causes the user experience to suffer as a result, then quality is affected. If this happens continuously on your project, then you will end up with something unusable or pretty close to that anyway. This is why it's important to keep track of that debt, and to ensure that you, as an XD, recoup it later down the line.

Why the weather forecast?

Everybody is familiar with weather forecasting symbols, for example Sunshine, cloudy outlook, rainy, etc...This is a useful language for people to use when talking about the quality of XD. I typically use a scale that runs from a rainbow experience to a thundercloud. This means that everyone on the team can understand what the quality of that particular feature is. I have used the scale on physical story cards to indicate how much of a compromise was made and what the resulting experience is. This can be subjective (the opinion of the XD team) or better still, come from user research results. You cold equally adapt this to express the current state of affairs from an XD perspective on a feature map, or as a subjective opinion from the XD team.

Benefits:

Everyone in the team grasps very quickly what the situation is, and they have an easy language to express it in. I overheard: "Well, we don't need anymore thunder" and "Is that a rainbow experience?"

It should be stressed not it's not always worth making everything a rainbow experience straight up. In our Agile environment, we expect a few cloudy experiences in the first iterations, but then the weather helps us to priorities where the XD work effort should be concentrated next. Sometimes rainy areas of a website will stay rainy for a while because they're not used as much as a cloudy experience on a very important piece of website real estate.

It is really really simple.

Try it out and let me know how you go :)

Resources:

Free vector weather icons

The truth about Yoga

photo credit: 68photobug Yoga and creativity has been a trendy topic recently in the innovation space. The thinking is that if you do Yoga then you will have more creative ideas and therefore be better placed to innovate. This isn't wrong, but maybe just a little simplistic. You may well have an awesome idea whilst in Pincha, but doing Pinch isn't the way to have one. What helps is simply calming down and through that, being in a space where you have the chance to really look at the world and yourself. It's peeling back the layers of judgment, opinion, likes, hates, loves, should/shouldn't, he did/she did,...all that stuff doesn't matter. When you get into a state of Yoga, I don't think even innovation and creativity are a goal anymore. Sometimes it can be a side effect.

What defines Yoga?

Yoga is not about bending yourself into a pretzel and doesn't really have anything to do with flexibility. "Asana", they physical postures, are but one of the 8 branches of Yoga. The full eight are listed in the Yoga Sutra of Patanjali, and they are:

- Yama: your ethical standards, or how you conduct yourself. There are 5 Yamas (Non-violence, truthfullness, non-stealing, contience, non-covetousness).

- Niyama: Self-discipline. There are 5 of these too (Cleanliness, contentment, austerity, self-study, surrender to something bigger than yourself)

- Asana: The physical postures

- Pranayama: Gaining mastery of the breath

- Pratyahara: Withdrawal of the senses

- Dharana: Meditation

- Samadhi: Basically, the experience of great peace

You have to be practicing all 8 (or at least have the intention to), regularly, to really say that you are practicing being in state of Yoga. Sharon Gannon says:

"You cannot do yoga. Yoga is your natural state. What you can do are yoga exercises, which may reveal to you where you are resisting your natural state".

Going to a Yoga class every day and then shouting at people while driving, drinking wine in the evenings and feeding yourself a ton of sugar through the day is not going to help you be more creative. If you are working stupid hours every day ask yourself why? Is it really for the joy of the work? Or is it to get promoted, to get a raise, to afford more stuff that you don't need? Yoga really is about everything you do in your life. Not just that hour you spend at a Yoga studio. It's about what you eat, what you say, how you treat people, your actions, their consequences, your intentions, your focus.

The most important thing to learn: Breathing properly

Breathing is very important. If you stop doing it, you will die. If you do it very badly, you will become ill. Can you think of a few people in your current meetings who have their shoulders up around their ears? It's impossible to get a full exhale by doing this, and they are often in a constant state of inhalation. This causes the body to be flooded with C02 and triggers the adrenal system. These people are unsurprisingly tense and anxious, or even angry. Can you think of people who hold their breath on the inhale in conversations, while they wait for you to finish? How do these conversations typically go? In my experience not so well. Encouraging people to hold the breath on the exhale (if they absolutely feel they have to hold their breath) is very useful.

When we focus on our breath and practice long slow smooth inhales and exhales we allow the body to shift into a state of homeostasis, that is, an ideal balance between stress and relaxation, alert but comfortable.

Our central nervous system is designed to cope with 2 natural states of being:

- Sympathetic nervous system is triggered by stress “fight or flight” - Parasympathetic nervous system is indicative of a relaxed state “rest and digest”

When we are stressed, taking long slow breaths, particularly on the exhale, we are reducing the effects of the sympathetic nervous system.

Yoga is a state of mind.

It is about developing the ability of the mind to remain focused on that which we choose to focus on, rather than on that which the mind tends to focus on. I often say that the mind is like a big puppy, very excited, difficult to control and potentially hazardous, as it jumps around sending vases and whatnot flying all over the place. When you try to meditate (like in seated meditation practice), it's as if you have put the puppy out on the balcony so you can get some peace. The problem is that it will bark, scratch at the door, whimper, anything it can do to get your attention, it will try. Yoga exercises are like throwing the dog a bone to play with. It soon forgets about you and you can get some peace finally.

To reach a state of yoga we need to calm down. There are many methods in Yoga practice to lengthen the exhale, so that the body and the mind can calm down. The body is a good way to the mind, but it's quicker to reach it through the breath. It takes seconds to begin to feel different. Incidentally this is why some say that "the postures are empty". They're just there to serve a purpose, to calm you down, to enable to come into yourself, free of self- judgment, free of self-punishment, free of self-opinion. Just you being you.

Once you get into that place, you can focus the mind on whatever you like. William James said "Our lives are the sum total of what we choose to focus our attention on".

Where is your attention focused?

WIFI painting: NFC awesomeness

This is a beautiful piece of work from the TOUCH project: "Touch is a research project that investigates Near Field Communication (NFC), a technology that enables connections between mobile phones and physical things. We are developing applications and services that enable people to interact with everyday objects and situations through their mobile devices."

The WIFI light painting project:

"This project explores the invisible terrain of WiFi networks in urban spaces by light painting signal strength in long-exposure photographs. A four-metre tall measuring rod with 80 points of light reveals cross-sections through WiFi networks using a photographic technique called light-painting."

Haunting, beautiful, clever, creative....awesome stuff!

Immaterials: Light painting WiFi from Timo on Vimeo.