I'm a product designer with a passion for user centered design. I am also an advocate of creative thinking approaches and design thinking.
I specialize in experience design for software. I've worked on lots of websites, web applications, mobile and social media products, applying principles and techniques from psychology and social sciences, human factors, human-computer interaction, visual design, accessibility and usability. My Ph.D focused on natural language generation and human communication with machines, a combination of AI and HCI.
I have a strong drive for innovation and have designed, envisioned and created new products for different market places and industries from scratch, as well as the strategy for bringing them to market and gaining user adoption. I bring the power and energy of design thinking to both startups and big companies. I like to focus my efforts on large-scale industry disruption.
I love to draw, take photos and skateboard. I'm a student and teacher of Yoga. I'm always exploring new things.
"Designers have the ability and the training to harness the tacit knowledge of the unconscious mind rather than being limited to working with explicit knowledge. This makes them good at synthesizing complex problems with large numbers of constraints. It also makes them bad at explaining or defining what they are doing or thinking. They will describe process and results because they are not consciously aware of their own rationale.
Experience design is as complex as any other kind of design and follows to some degree the same processes. We look at problems that sometimes can be solved through logic and attention to detail, but the most interesting and far reaching challenges we take on cannot be solved in that way. They require highly divergent thinking, an excellent filter to narrow those possibilities down, and a fearless resolve. The work must be done, there are no epiphanies.
We often begin with introducing ourselves to the challenge, understanding the breadth of it, seeking any foothold onto that colossal and perplexing wall of ice. Have others been here before, and what paths did they take? What tools will help? What is within reach? Have I climbed something similar before?
You walk around this thing, playing through your head a million scenarios, remembering hundreds of things you've done before and pooling all your energy into understanding the problem. At some point, you'll exhaust yourself as you reach yet another dead end, yet another hurdle. Your solutions are not solutions at all, they're investigations that end in frustation. At some point you have to stop investigating and explore.
Exploration should be free of what has been, the knowledge you have accumulated and the things that you know. This is a new problem, and learning can only be experienced in the now, not in the past of your thoughts and ideas. You need to look at everything with beginner eyes, and have a sense of naive appreciation for the wild landscape around you. Stilling your mind from the noise of the inner monologue will allow you to experience all facets of the problem as it stands, not how you imagine that it is. You'll notice small things that look new to you now that see them, and you'll relax and stop to judge yourself and the situation. Where there is conflict there can be no freedom. Creativity can only exist in freedom.
Finally you'll be still long enough to hear the solution. It has been there for longer than you know, just you needed to slow down and quieten down to hear it through the chaos that is a mind in agony over a problem. The first thing you will do is draw or jot down some words, lo-fi, easy and tactile. The more you try and think, the harder it is to hear it clearly, so experiencing is the only way forwards. By prototyping and playing with the thing, you craft something that makes you smile. Something that makes you feel that vibration of joy that only comes from reaching this point on this kind of journey. It's only just begun though.
You are at the gross end of the spectrum. You are moulding your solution from fresh discovery as you experience it. It has rough edges, it is ugly, it is incomplete and raw. Yet it is full of promise, and insight. It's likely that its hard for others to understand it, without you taking them on the journey you have been on, so they also can share in its awkward awesomeness. It is probably but a few lines of sharpie on the back of a napkin after all.
After many many rounds of refinement, it will be a sophisticated, mature and fully thought through, original solution. It is subtle. Those who use it as a final product will feel the intensity of it, although they may not understand that vibration they get from it. They will break into a smile, be filled with passion using your product, and never really know how far you had to go to retrieve it. You sweated the details down to the last one. That's part of the beauty. When the work is not done, when the journey from gross to subtle is not travelled, you can tell. You feel the shallowness of it, you feel the immaturity in the work.
Either they failed reaching exploration because they pressured themselves to design a solution immediately, fearing the great unknown. Or they having never been on the journey, they never knew it was there, taking a bludgeon to the wall of ice instead of failing to se the possibilities.
In the gross end of the spectrum live sketching, brainstorms, and mappings. How does it work and does it fulfil their need? At the subtlest end of the journey there is look and feel, colour, texture...does it delight and consume them? This is a long journey for products, with many iterations in between, on the spectrum. It requires everything you have: left and right hemispheres, all your time, all your energy and all your courage.
This is the work of design. Although led by individuals, it is successful only in teams, for you will need the richness that different perspectives offer. For many, it is their first journey, and as the designer it is up to you to guide them through it to the other side and give them heart in the steep mountains.
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.
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!
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.
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.
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.”
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")
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.
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.
photo credit: poppet with a camera
I read a lot of books, especially about experience design, consulting, Agile and innovation. The last few months I've read a seriously good batch of XD books, and I wanted to share with you those titles. I think they're useful for people both new to field and the vetarans too. There's such a wide choice of books around this relatively new subject, and there are a lot of useless ones too unfortunately. This list has a bunch of books I enjoyed reading and that I find useful as reference works. Enjoy.
"In Seductive Interaction Design, speaker and author Stephen P. Anderson takes a fresh approach to designing sites and interactions based on the stages of seduction. This beautifully designed book examines what motivates people to act."
"Early user interface (UI) practitioners were trained in cognitive psychology, from which UI design rules were based. But as the field evolves, designers enter the field from many disciplines. Practitioners today have enough experience in UI design that they have been exposed to design rules, but it is essential that they understand the psychology behind the rules in order to effectively apply them. In Designing with the Mind in Mind, Jeff Johnson, author of the best selling GUI Bloopers, provides designers with just enough background in perceptual and cognitive psychology that UI design guidelines make intuitive sense rather than being just a list of rules to follow."
"Universal Principles of Design is a comprehensive, cross-disciplinary encyclopedia of design. Richly illustrated and easy to navigate, it pairs clear explanations of every design concept with visual examples of the concepts applied in practice. From the "80/20” rule to chunking, from baby-face bias to Occam's razor, and from self-similarity to storytelling, every major design concept is defined and illustrated for readers to expand their knowledge."
"Design is explained, with the means and manner for successes and failures illuminated by engaging stories, true examples and personal anecdotes. In Sketching User Experiences, Bill Buxton clarifies the processes and skills of design from sketching to experience modeling, in a lively and informative style that is rich with stories and full of his own heart and enthusiasm. At the start we are lost in mountain snows and northern seas, but by the end we are equipped with a deep understanding of the tools of creative design."
"Neuro Web Design employs “neuro-marketing” concepts, which are at the intersection of psychology and user experience. It’s scientific, yet you’ll find it accessible, easy to read, and easy to understand. By applying the concepts and examples in this book, you’ll be able to dramatically increase the effectiveness and conversion rates of your own Web site."
"There is no single methodology for creating the perfect product—but you can increase your odds. One of the best ways is to understand users' reasons for doing things. Mental Models gives you the tools to help you grasp, and design for, those reasons. Adaptive Path co-founder Indi Young has written a roll-up-your-sleeves book for designers, managers, and anyone else interested in making design strategic, and successful."
"Effectively measuring the usability of any product requires choosing the right metric, applying it, and effectively using the information it reveals. Measuring the User Experience provides the first single source of practical information to enable usability professionals and product developers to do just that. Authors Tullis and Albert organize dozens of metrics into six categories: performance, issues-based, self-reported, web navigation, derived, and behavioral/physiological. They explore each metric, considering best methods for collecting, analyzing, and presenting the data. They provide step-by-step guidance for measuring the usability of any type of product using any type of technology. "
"Adeptly address today’s business challenges with this powerful new book from web analytics thought leader Avinash Kaushik. Web Analytics 2.0 presents a new framework that will permanently change how you think about analytics. It provides specific recommendations for creating an actionable strategy, applying analytical techniques correctly, solving challenges such as measuring social media and multichannel campaigns, achieving optimal success by leveraging experimentation, and employing tactics for truly listening to your customers."
"In this all new edition of Communicating Design, author and information architect Dan Brown defines and describes each deliverable, then offers practical advice for creating the documents and using them in the context of teamwork and presentations, independent of methodology. Whatever processes, tools, or approaches you use, this book will help you improve the creation and presentation of your wireframes, site maps, flow charts, and other deliverables."
"One of the web designer's greatest challenges is to create a site distinctive enough to get noticed among the millions of sites already on the web. This book examines the bond between code, content and visuals to guide you through the factors that increase your design's visibility, usability and beauty. Using this practical advice, even web designers who lack strong artistic skills can develop super sites that strengthen the message and stand out from the crowd."
"The grid has long been an invaluable tool for creating order out of chaos for designers of all kinds—from city planners to architects to typesetters and graphic artists. In recent years, web designers, too, have come to discover the remarkable power that grid-based design can afford in creating intuitive, immersive, and beautiful user experiences.
Ordering Disorder delivers a definitive take on grids and the Web. It provides both the big ideas and the brass-tacks techniques of grid-based design. Readers are sure to come away with a keen understanding of the power of grids, as well as the design tools needed to implement them for the World Wide Web."
"New research on emotion and cognition has shown that attractive things really do work better, as Donald Norman amply demonstrates in this fascinating book, which has garnered acclaim everywhere from Scientific American to The New Yorker.Emotional Design articulates the profound influence of the feelings that objects evoke, from our willingness to spend thousands of dollars on Gucci bags and Rolex watches, to the impact of emotion on the everyday objects of tomorrow.Norman draws on a wealth of examples and the latest scientific insights to present a bold exploration of the objects in our everyday world."
"In this thought-provoking book, based on nine years of research in captology, Dr. Fogg reveals how Web sites, software applications, and mobile devices can be used to change people's attitudes and behavior. Technology designers, marketers, researchers, consumers-anyone who wants to leverage or simply understand the persuasive power of interactive technology-will appreciate the compelling insights and illuminating examples found inside."
"We design to elicit responses from people. We want them to buy something, read more, or take action of some kind. Designing without understanding what makes people act the way they do is like exploring a new city without a map: results will be haphazard, confusing, and inefficient. This book combines real science and research with practical examples to deliver a guide every designer needs. With it you’ll be able to design more intuitive and engaging work for print, websites, applications, and products that matches the way people think, work, and play."
