At MidwestUX, I gave a shorten version of my upcoming STC Summit presentation. For those of you that came to my talk, thank you for your time and attention. For those that were not able to make it, below you will find a recap of the material I provided to the crowd. Really quickly, I’d like to thank the MidwestUX team for putting on a great conference, and for allowing me the chance to be a part of the event.

One of the best ways user experience professionals can build an empathic link with people, is to interview them in their homes, or their personal environments. Doing this comes at a risk though. Not a physical risk per se, but an emotional and mental risk. You learn about extremely sensitive information and you hear such emotional stories that it can eventually take a lot out of you, not only as a designer but also as a person. 

Midwest UX Slides

STC Summit Slides

The research that provided the content for this presentation came from my own experience doing user research with cancer patients and their caregivers, and interviewing people about their personal finance, specifically their retirement funds. Supplemental material was provided thanks to Whitney Hess and Erin Jo Richey, based on research they performed as well. After going back and reviewing all the various interviews I’ve done in the past, I found that many people fell into certain themes. The best way to describe these themes is by using the movie genre metaphor to categorize them.

Suspense

These are people with engaging stories that just capture your attention. Interviewing someone that falls into this genre really requires you to engage with the participant. You want to follow their story, going as deep as it may go. This may require you to go “off script” sometimes. It’s important to remain focus though, and don’t go down too many rabbit holes. You’re there to collect a certain amount of specific information and you don’t want to miss your chance.

Drama

These interviews are very emotional, and they leave you with a lot of baggage. They will haunt you for years to come, and in certain respects they can over-shadow the other participants in the study. Because these stories stick with you so strongly, I encourage you to develop some method that allows the other participants to stand out. My method was to give them nicknames based on an interesting aspect of their life, or something I noticed while sitting at their dining room table.

One important factor about interviews that are very dramatic, is the fact they are extremely emotional. It’s very possible that emotion will begin to effect you during the interview, even to the point they make you start to cry. This is totally acceptable, but at this point the interview is over for the most part. You can continue asking questions, but your way of thinking, and the way you process the information you are collecting will be affected by your emotional state.

Comedy

These interviews are just down right fun. You’ll quickly find yourself not only enjoying yourself immensely, but engaging with the participant on a whole new level. Because these in-home interviews have such a fun factor associated with them, time just flies by. So it’s important to keep an eye on the clock, and ask all the necessary questions to collect the appropriate data.

Participants that are good at telling funny stories can be a life saver though when you’ve already been exposed to very dramatic session. These remind you that not all is bad in the world and to not take everything so seriously. It’s easy to want to become buddy-buddy with these interview participants, but I would caution against it. It’s ok to joke around and laugh, but you still need to maintain a barrier between you and them to ensure you maintain your researcher role.

Thriller

You’re in for a shocking time with these types of in-home interviews. People will mention things very candidly that can be really off base, or you might notice something around their house that puts you on edge. It’s vital to never act surprised when these things happen, or to draw attention to them. However, if it gets to the point where the overall interview has become so uncomfortable, it might be necessary to put an end to it. Thank the participant for their time, give them their honorarium, and simply leave.

Documentary

Interviews that focus on a shared event or experiences are unique. This genre comes from the experiences Whitney Hess had while performing user research for the U.S. Holocaust Museum in Washington D.C. This is another time where emotions can run wild, especially if the focus of the interview is a traumatic event. Whitney recommends that you build an emotional wall up on the inside, and that the time to deal with your personal emotions is when you are reviewing all the data that was collected.

Foreign

Cultural difference can wreck havoc on your research if you aren’t properly prepared. Erin Jo Richey ran into this problem while performing user research in Italy. When it came time to provide the participant with their honorarium, they would refuse it. This was because the Italian participates thought of their participation as an honor, and not something they should get paid for. This is just one example of a cultural difference causing issues during user research, but it is something that can easily pop up numerous times if you are interviewing people abroad.

General Takeaways

I also provided some generic advice and steps other user experience professionals can take to best prepare for doing in-home user research. These included:

The Buddy System – Never go alone, not just for your own safety but for the participants as well. People actually feel more comfortable welcoming two people into their home rather than just one.
Be “On Time” – Being late is a huge taboo when you are meeting with someone at their home. I recommend showing up about five minutes early, and if you KNOW you’re going to be late call ahead of time.
Welcome Packet – Prepare a little welcome pack and mail it to the participants a few days before the actual interview. This should include pictures, bios, project background information, and supervisor/client contact information.
Humanize Yourself – This is best done by taking a glass of water if offered one. By doing this, you become a guest in their home rather than some stranger coming to study them.
Be 100% Honest – Never lie or deceive someone who is inviting you into their personal space. You need their trust to collect good information, plus doing otherwise is very unethical.
No Loitering – Once the interview is over … leave. Don’t debrief outside on their sidewalk, or in the car while still parked on the street. Drive to a nearby coffee shop and do it there.

I will be giving an expanded version of this talk at the STC Summit next month. If you have done extensive user research in either people’s home or some other personal environment, what are some lessons learned that you might have for user experience professionals preparing for this type of study?

In Part 1, I argued that the need for a designer to know how to code what they create is based on the designer’s chosen professional path and the overall size of the project they are working on. This has resulted in a variety of great comments, both here on the blog and on the twitterverse. If you haven’t had a chance to read it, please check it out.

Having dealt with that side of the argument, I want to provide some thoughts on why it’s important for designers to know about code, understand what a development lifecycle looks like, and why knowing these two aspects of digital creation is vital to being a well rounded designer. As I mentioned in the previous post, my educational background is in Computer Science. There are very few aspects of the coursework that I use in my everyday work, but what I do use is the concepts and domain knowledge that came along with it. Because of the curriculum I have a fundamental understanding of Object Oriented Programming, System Architecture, and the theory behind programming languages and their structure.

How does that help me as a designer?

Having this knowledge allows me to understand the medium I work in, at its most fundamental levels. At a high level, I understand what the technical constraints are on a variety of technical platforms. This understanding ensures the final design isn’t super difficult or complex to develop.  Later on in the overall process, when a developer challenges a design decision or offers up a suggestion, we can speak using the same language. We are able to collaborate more effectively on a problem because we have a shared understanding of the technical concepts that are required to make up a design.

How could this knowledge help you as a designer?

Effective collaboration

Being to speak the same language between you and another party is the first step to effective collaboration. This is something we do when working with users and business folks right? Why would it be any different when we are working with our technical peers? The good news is the craft of interactive prototyping is a great tool to use to facilitate a technical conversation. If you understand, at a fundamental level, how a particular interaction would need to be implemented, you are poised to better communicate that requirement to a technical team. Doing this with an interactive prototype isn’t the only option. As part of the interaction design spec, you could write out the interaction as pseudo-code. But, for the pseudo-code to be meaningful, it needs to be based on an understanding of the technical platform you are designing for.

More Marketable

It common to find that many User Experience Designers comes from either a psychology or traditional graphic design background. This background is necessary to effectively research user needs and behaviors, and to create a solution that meets those needs and supports those behaviors. However, if you obtain a working knowledge of the development side of things it allows you to contribute to areas of the design process that may not directly relate to user experience design. Also, your opinion on non-user experience design aspects of the system carries more weight. Other members of your team will put more trust in your designs and you, as they understand you’re not going to design something crazy and unmanageable.

Encourages Innovative Work

With solid foundation of what’s been done in the past and is currently being done within a particular technical platform, you are best prepared to design something new and innovative. Granted this depends on the project your working on, but innovation is possible on either the micro or the macro level. You will be better prepared to know when it’s time to break the rules and do something that’s disruptive or unfamiliar to either your organization or your audience. We already know this rule works out based on all the work that’s been done with design patterns. The best way to know when NOT to use a design pattern is to have an intimate knowledge of that pattern.

No Excuses For Not Learning

Knowing how to code what you design isn’t required to be a good, if not great, designer. But it doesn’t hurt. At the very least, a designer should have an understanding of the working fundamentals of the technical aspects of the medium in which he or she works. With the amount of information that is available online, in books, or even at local community colleges, the barrier to learn is very low. My recommendation to anyone that wants to beef up their skill set, or at least domain knowledge, on the technical aspects of the web is to pick up a book and build a “Hello World” application or webpage. Even doing something as simple as this will give you insight into what it takes to bring your designs to life and allow you to empathize with your technical peers.

If you are a designer who always goes to design conferences, break out of your comfort zone and attend a technical conference. Better yet, speak at one. It’s been my experience that technical conferences are very open to speakers from the design world. If attending, or speaking at conferences, isn’t your thing, go to local tech meet ups in your area. Not only is this a great networking opportunity for you but it’s a great place to find a mentor. It’s been said that to become a better design just design something. I’d refine this to say, “To become a better designer, design and build something…anything!”

At SxSW this year I attended a panel that meant to tell designers that there isn’t any excuses not to know how to code anymore. Putting aside some general complaints I had about the structure of the panel, I had a problem with the overall message the panel delivered. The claim: that to be considered a true designer, you must know how to code what you design, is misguided and in the end harmful to the profession of user experience.

What Makes For A Good Design?

Being a good designer isn’t founded in your ability, or inability, to code. Rather it’s based on the ability to think systematically about the particular problem space you’re working in. Understanding the What and Why behind a process or solution is a different skill set than knowing How to bring it to life. It’s the old argument of what’s more meaningful, right brain thinking or left. The truth is they are both meaningful in their own right, both are needed in world we find ourselves in today, and you need both for any design problem to be properly solved. To learn more, check out Daniel Pink’s book “A Whole New Mind.”

In addition to being able to think systematically, a good designer needs to be skilled in good, clear communication. Being able to think through the What and the Why of a problem only gets you so far. Without the ability to communicate those ideas in a meaningful way, all that brain power is meaningless. Communication can come in the form of visual or written work and yes, even code. The work that creates the greatest impact are those that combine visual and written ideas in a meaningful and compelling message.

How does this apply to User Experience Designers?

The role of a User Experience Designer is intentionally vague and open to interpretation because its specific meaning is dependent on the context they are working in. I believe there are three flavors of a User Experience Designer that can be found in the design world.

The Unicorn

The Unicorn is found on smaller projects where the skill set is broader due to necessity. Here you find those designers that know the how to perform research, conceptualize it, design it, and build it. This is the type of designer that needs to know how to code what they create because the projects they work on are smaller and and by a handful of people. They are able to manage the entire process, controlling the overall scale and complexity of a project. This can best be explained by relating it to an architect that has decided to design and build a dog house. It’s small enough that he can blueprint out the design, gather the material, and perform the labor to bring it all together.

Generalist

Generalists are designers that have a wide variety of skills, that may go deep in a few areas but are adaptable enough to tackle things they are merely familiar with if need be. They are flexible enough to jump in at various stages of the design process and provide guidance or partner with an expert to collaborate. Due to these attributes, Generalists are available to work on medium to large projects that require a teams made up of a variety of roles  to accomplish complex goals. I’d wager that this is the average User Experience Designer found in industry. Being a Generalist isn’t inherently a disadvantage, that’s why we see HR Generalists holding more predominate positions than say a Benefits Administrator. They are able to contribute to an HR department in a variety of ways, and in many cases you find that HR Generalists are the ones managing the overall efforts of a department.

Specialist

Specialist have a very focused and very narrow workflow and resulting impact on a project. This is by no means a bad thing! Specialists are invaluable and usually required for large scale and complex projects. For these types of projects, it’s important to have a team made of User Researchers, Information Architects, Interaction Designers, Visual Designers, UI Developers and countless other roles. To see the value of the Specialist, we can look to Medical Surgeons. Last year my father-in-law was diagnosed with stomach cancer, and it was determined that he would need his stomach removed and rebuilt using part of his colon. Given the complex nature of the procedure and the various body systems that were involved, this surgery required the skills of two specialized surgeons. This was not a procedure that you would want a family practitioner to perform.

The Importance of These Three Roles

Within the focus of the User Experience profession, we need a good mix of all three of these types of designers. We need those that can tackle the entire process, as they are great mentors for those that choose not to, or haven’t built those skills yet. We need designers that are able to work on larger projects assuming a variety of roles or as a focused specialist to ensure the project comes out successful.

It’s my experience that the type of designer you become is up a matter of personal preference and professional goals. Personally, I like being a Generalist. I like doing a mix of user research, interaction design, and jumping in a tackling some information architecture and usability work every now and then. Given my background with a Computer Science degree, doing some development work is within my capabilities, but I’d rather partner with a skilled UI developer and leverage their focused skill set rather than hack my way through it.

Being a Generalist is my personal niche, it’s what makes me happy as a User Experience Designer. Sure one day that might change that I will choose a specific focus. Or I might choose to leverage the coding background I have, build out my visual design skills, and begin to tackle projects from start to finish.

Again, it’s my personal choice to define the type of designer I want to be. How do you determine what type of designer you are?  If you want to be someone that can manage the entire process from start to finish, then you better be willing to learn how to code. If you like a variety of challenges in your daily work life, then find a few areas of the UX spectrum and kick ass at them. If you are passionate about a single particular aspect of UX, then dive deep and dive hard. Where you find yourself, don’t let others distract you or detract you from your professional growth based on how they define the world.

In Part 2, I’m going to present the other side of this argument, but from my own point of view, on why designers need to know about coding. Look for it to be posted later this week.

I recently returned from SxSW where I was given the honor and privilege to co-present with Chris Risdon and Nick Disabato. Together we presented a 2.5 hour workshop on Behavioral Design and Persuasion. The workshop was split into three parts, with Chris covering the general theory behind Behavioral Design and Persuasion, Nick going into details behind specific concepts around Persuasion and showcase many great design patterns, and I was tasked to cover the ethical side of doing Behavioral Design. Overall, our talk was a huge success in my book and I want to thank both Chris and Nick for including me on this amazing journey.

In an effort to provide additional information for those that either didn’t stick around for my portion of the talk, or those that couldn’t make it, I’m posting what was fundamentally what I said during my presentation.

Why Ethics Matter

So why are Ethics important when it comes to doing behavioral design? I firmly believe that any type of behavior encouragement or change is some form of manipulation. Now, it’s important to note that there is good manipulation and bad manipulation. Getting me to sign up for your newsletter because you purposely used double negatives in your labels,  and then making it impossible for me to unsubscribe is a great example of BAD manipulation. On the other hand, getting me to acknowledge that my wife and I spend too much money at Target and encouraging me to save more is a form of GOOD manipulation. Ethical Philosophy is something that allows us to ask tough questions during the design process so that we avoid the bad manipulation and take advantage of opportunities to incorporate good manipulation.

The wonderful thing about Ethical Philosophy is that many of the theories can easily be distilled down to tangible frameworks that can be used guide the design process. If used early on in a project, they can be a guiding light that ensures the end product is as Good as possible. These frameworks can also be used during various check points of a design lifecycle to act as a gut test for the team, and get them back on track if need be.  Regardless how or when you use these frameworks, their main benefit lies in the questions they force you to ask yourself, team, and stakeholders.

Virtue Ethics

Virtue Ethics originated based on the work of Plato and Aristotle. The crux of Virtue Ethics is to live a balanced life, using the defined nine virtues as a guide to maintain that balance. If you are unbalanced in one or more areas, the concept is to begin acting (or pretending) in the opposite fashion. For example, if you are generally cowardly or easily scared, act brave and courageous. Eventually, you will stop acting (or pretending) and simply BE brave and courageous. Now, this is a very simplisitc explanation of Virtue Ethics, but it gets the point across.

How does this apply to behavioral design? Many applications exist today that track our everyday behavior, and report back on that behavior. The advantage of this technology is that we are becoming more aware of how deficient, or in excess, we are regarding our behaviors. A design that follows the Virtue Ethic framework is one that encourages or pushes a person to no longer be deficient or in excess. Mint.com is a perfect example of a design that fits into this framework. When I first using Mint.com I quickly noticed that my wife and I on average spent well over $300 dollars a month a Target. Compared to the national and local averages, we were spending too much money at Target. This allowed us to evaluate our spending habits when we visited Target and encouraged us to buy what we needed rather than what we wanted. It took a behavior that was in excess and brought it closer to something that is more balanced.

Categorical Imperative

The Categorical Imperative is defined by Immanual Kant in his philosophical work
Groundwork of the Metaphysic of Morals(PDF). Kant wanted to create a rule based system to morality that could be used to gauge any action or behavior. To this end he defined the following three maxims as a series of questions you could ask yourself when trying to determine if an action is moral or not. Firstly, you ask yourself if someone else was in your exact situation and they performed this act would it still be considered Right? Next, determine if you are using another person in some way by performing this act. Kant strongly believed that one person should never use another person, that we should always treat a person as an ends and never as a means. Finally, ask yourself if your action was a universal law, one where everyone in your situation and context was forced to act this way, would it still be Right? By going through these three morality “tests”, you can determine if a particular action is moral or not.

How does this apply to behavioral design? It’s a common practice for designers to use some type of pattern library to influence or inspire their work. Architects do this as well, starting with a common, proven base to begin their work. Looking at the Musical Paino Stairs created as part of Volkswagen’s The Fun Theory, we see a pattern that would be moral when put through the Categorical Imperative. If everyone, that was healthy and capable, had to use the stairs rather than taking an escalator, and it was “fun” to do, the world would probably be a slightly better place. People would get more exercise, burn more calories, and generally be more healthy. (In theory.)

Utilitarianism

Everyone wants to world to be a happier place, it’s only a few sick individuals out there that try to mess it up for the rest of us. Utilitarianism is based on the concept of equating morality to the overall level of happiness, or utility, that gets added to the world by performing an action. To determine this, the Felicific Calculus was created that allows you to compute the “exact” amount of happiness, or utility, an action adds, or removes, from the world. Two aspects of this formula that stands out to me are the chances of an action being repeated and the amount of people it impacts.

How does this apply to behavioral design? Applications or special social based programs can have a large influence on ones behavior and life style. Looking at the Evoke “game”, we find a great example that not only taught people in third world countries key survival skills, but it also inspired a group of entrepreneurial minded people to create businesses that help others adopt these survival skills.  This program not only affected a large amount of people, but it’s having lasting effects well after the first “season” concluded.

Altruism

The debate on if true Altruism exists has been around for a long time. Luckily, from a philosophical point of view it’s well and alive. The moral theory of Altruism doesn’t really have any type of creator, as it’s based on our very own evolutionary history. The basic concepts of Altruism can be found by studying the way humans behaved when we were restricted to a tribal based society. One of the most basic rules of any tribe is that an act must be one that, in the end, benefits the entire tribe. For this to work, everyone in the tribe was required to give something up for others, and accept something from their fellow tribe-mates that they in turn had to give up.  Everyone relied on everyone else sacrificing something for the benefit of all.

How does this apply to behavioral design? Several applications have popped up recently that are based on either a pseudo-barter based economies, or that attempts to help others without asking for anything in return. For this framework, I’d like to focus on ReadyForZero.com as an example of a product that is very altruistic in nature. ReadyForZero’s main goal is to help others gain control of the credit card debit, offering payment plans, advice on debt consultation or consolidation, and even go so far as to bring up the possibility of claiming bankruptcy. All of this is offered for free, in other words the creators of ReadyForZero took the time, effort, and money to create something to help others. Now, that doesn’t mean they don’t have a business model of some kind to make money for themselves, which they do. But it shows an example of helping others to help others, which eventually will help yourself.

Doing “Good” work is hard, and it’s something many designers strive to do. The drive to do “Good” is fueled by designers attempting to make the world a better place, even if it only impacts a small group of people. These frameworks are an effort to provide designers with the tools to gauge their work from a moral and a practical point of view. They encourage tough questions to be asked, questions that try to get at the “Why?” of a decision rather than the “What?” and “How?” Given the history that goes along with these four frameworks, it also gives designers plenty of rationale and resources to defend decisions they make when challenged by managers or directors.

This question gets asked in a variety of online forums and Q&A communities all the time. We also hear it offline coming from stakeholders and clients when projects are getting kicked off, or when designs are being reviewed. Fortunately, this question has a simple answer – YES! Now, the rationale behind the answer is where it gets tricky, and for all you out there that are a fans of User Research it’s where the fun happens. 

There is always someone, or a group of someones, that will use a particular feature or function. It could be personal preference, or some person out there has determined that using said feature is more efficient/productive than the standard method. The sad truth though is just because people use something as it appears on other sites and products, doesn’t mean it’s the right thing to do for your design/product. To make a truly informed design decision, it’s best you put yourself out into the world and do some good ole research.

Go find a group of people that represent your users and see if they are even aware of the feature you’re thinking of using. This can easily be done with a 15 minute conversation over coffee, or over the phone. If face to face interaction isn’t feasible, crank out a short, and I mean short!, online survey. You should pay close attention to WHEN people use the feature, and most importantly WHY. Other areas of interest should be when people DON’T use the feature, especially if you happen to run across someone who purposely AVOIDS the feature. All of these little data points are great starting points to have a meaningful and inspiring conversation with people who you will be designing for. The results of the conversation will allow you to answer “Do people use <Insert Feature/Function>?” with an informed response and help convince others how time and money should be invested during later stages of design and even development.

Based on several articles I’ve read over the past months, and the session Eric Reiss gave at last years IA Summit on ‘ROI: Speaking the Language of Business‘, I wrote out this mind dump of how I think about selling User Experience. These ideas are fairly rough and are intended to see how closely my thought process aligns with that of my peers. Hope you enjoy!

Begin mind dump

They just don’t get it?

This is the wrong approach and leads to over discussing the variety of methods and techniques that exist in the world of user experience. Rather, we should be asking why we don’t get it? The people that have the ability to hire our services don’t care about paper prototyping, usability studies, or ethnographic interviews. They care about the value these activities can bring to their organization and how quickly they will be able to see that value manifest.

Defining the Value

Every project has a goal, and it’s that goal that determines what type of value needs to be provided by the project.

Examples of Project Goals (Reference):

• Insight into how the site/application users will think, act, and react when using the site/application
• Confidence that their site/application will function as a cohesive whole.
• Stakeholder consensus on what will be built and why it is being built.

The particular methods and techniques needed to discover, define, and provide the appropriate solution for any of these goals is dependent on context, environment, and culture. With this in mind, the sales process should be focused on defining what the client’s goal is for the project, and delivering a plan in which to accomplish that goal. Activities should be talked to at a high level until the project has been landed and the initial problem space explored.

Discovering Problem Space

The exact method in which a problem will be solved should never be defined until the problem space has been explored and defined. This can be accomplished either during the sales pursuit, or as a phase 0f a project. Defining the problem space is done by conducting internal stakeholder interviews, relying on past user research, or referring to research done by others. The outcome should be a detailed plan of user research, analysis and modeling, time to design, and validation. This can take the form of a follow up proposal, or as a set of recommendations for them to internalize and use as they see fit.

Yes, there is a danger of losing the project after this proposed initial phase, but the likelihood is low as the team will have established themselves as partners and give the client a clear understanding of how the end solution will deliver the value they are looking for. The pay off for this risk are longer and more in depth projects.

Planning UX Activities

There are a variety of possible activities that can be performed to design a solution for a given problem. Some activities are better than others however, given a particular context. In fact, the final set of activities should be laid out only after the team has a clear understanding of the client, user base, and problem space. There is no such thing as the silver bullet in User Experience, and it would be a mistake to act any other way.

When pitching proposed activities, the overall process and end deliverables shouldn’t be the topic of discussion. Rather, give a detailed explanation of the value each activity brings and how that value will assist with the next stage of the overall process. Speak the language of the client, industry, and user base when expressing the value. Don’t bog it down with professional jargon that needs to be explained.

End mind dump

I recently had the pleasure of being a guest on Jeff Parks i.a. podcast. This was my first time being both interviewed and recorded, and kudos to Jeff for making it an awesome experience! The conversation we had revolved around failure and why it’s so important for designers. The topics include concepts I brought up in my three part posting on the importance of failure, and feedback we received on the wiki he set up. Thank you to Christian Crumlish, Daniel Szuc, Jan Jursa, Valeska O’Leary, and Eric Reiss for that feedback btw! You can listen to the podcast either here or via iTunes. Hope you enjoy!

In the final part of this series on the importance of failure, I’ll be getting a little philosophical on the subject. Part 1 and Part 2 covered some practical means to take advantage of failure. The final two methods are meant more to change the mindsets of both individuals and organizational leadership to encourage an environment that takes full advantage of failure. Failure always has a negative connotation to it, and these final two approaches are perfect for finally putting a positive spin on the subject.

Embrace Failure

It’s a natural human response to put up our defenses once something goes wrong and we are deemed at fault. This response normally comes out as a series of excuses, attempting to divert the blame to others, or just hanging our head low while the situation steamrolls everyone over. A better response would be taking control, and asking questions like ‘What could I have done differently?’ or ‘What did I miss that lead to this?’ Not only is this the more professional, but it can jump start the conversation towards finding possible solutions.

Conversation Points:

• What kind of policies should be in place to encourage failure?
• How serious does a failure need to be before serious action needs to be taken?
• How does traditional damage control fail to inform project teams and designers on how to avoid the same mistakes again?

Open Minds and Open Ears and Open Hearts

Negatively responding to someone who has made a mistake does nothing to resolve the overall issue. In fact, it makes the whole situation that much worse. Keeping an open mind that everyone screws up every now and then, listening to what lead to the failure, and supporting someone in picking up the pieces greatly is whats need to  improve the situation. This is the keystone to turning everyday design failures into a positive aspect of designing.

Conversation Points:

• What was the worse project/design review you’ve had that did nothing but point out all the flaws and didn’t offer any tips for improvement?
• How do you empathize with a peer on their failure, but still maintain a sense of authority?
• Obviously, there is such thing as failing too much and too often. Where should this line be drawn?

This closes the proposed framework on how to deal with failure as a designer and use our failures to ensure the work we do tomorrow is a vast improvement to the current ‘disaster’ that is causing so much heartache today.

In Part 1, I showcased the first two methods for dealing with failure and learning from it. Part 2 will focus on activities that can be during a retrospective, or stand alone. These next two methods have a certain risk associated with them due to the emotions that can arise during the resulting conversations. If done successfully however, the passion these emotions invoke can help solidify the lessons that are available to be learned.

Assign Blame

There are some that believe that a single person can shoulder the responsibility of an entire project. The truth is though, whether a project is large or small this is impossible. The responsibility of a project is a partnership of the team, even if it’s a team of one, and the sponsoring client. The advantage of this shared sense of responsibility is that when something goes wrong it’s possible to pin point who was the cause. There are many dangers associated with calling someone out, but if done in a respectful and constructive manner it can be a great motivator.

Conversation Points:

• How have you dealt with being call out when you were responsible for a project failing, or an aspect of the project going a-rye?
• Have you ever had to assign the blame to a project member? How did you approach them?
• What are some safe ways for assigning the blame to someone?
• Does the emotional risk outweigh the possible benefits of pin pointing the person responsible for a mistake?

Highlight the Success

All this talk about failing and finding faults in people can eventually become too negative. No project is a complete and utter failure. Shedding light on the successes helps give the team, and the client, a positive view on the overall value of a project. It helps bring the team back together, and if the client is involved it makes them feel better about investing in the project. Talking about all the stuff that was a success helps to mitigate the negative emotions that may have popped up over the course of the conversation as well. Yes, Bob might have delayed the project a week due to a database issue, but he really hit a home run optimizing the database making the app super quick. In the end, a nice pat of the back goes a long way.

Conversation Points:

• What is more difficult, highlighting failures or successes?
• What is the proper ‘reward’ for someone being responsible for a big success?
• Should highlighting a person’s success be public or private?

Related Posts:

Part 1 of The Importance of Failure for Designers

Part 3 of The Importance of Failure for Designers

I’ve recently been working on a framework to help designers deal with failure. Failure can occur many times over the course of a project, and knowing how to use that failure effectively helps a team continue to work without losing steam. Over the next couple of weeks I’ll be posting the methods I’ve identified two at a time that form the framework. The goal of these posts is to gather feedback on the value of these methods, and any suggestions you want to see that will help flush them out. In other words, have a nice virtual conversation around how to scare off the bogeyman that is Failure.

Retrospective

The recent popularity of Agile has helped bring about the importance of a retrospective. Performing a retrospective is a great tool for looking back and identifying the problem areas that occurred over the course of an iteration or project. This activity can, and should, occur throughout the entire course of a project. The earlier problems are identified, the quicker they can be dealt with. This is especially important in the world of design, and software development as a whole, since the longer a problem persists the more expensive it is to fix.

Conversation Points:

• What have been some of your experiences with retrospectives?
• How did you handle the pressure when a problem area was identified that you were responsible for?
• How have retrospectives made you a better designer?
• Have retrospectives ever failed to improve things? Why?

Document Warning Signs

There is little value in identifying our failures if we don’t learn from them. Any failure can be traced to a particular step, or event, that was the catalyst the calamity. Cataloging the missteps that were the ultimate cause of a mistake is great approach to ensure the lesson hits home for a designer. Having this history both helps for posterity, and serves as an early warning system in order to avoid the same mistakes in the future. A designer should look at their book of failures as a matter of pride, proof of all the experience they’ve had dealing with issues that can come up over the course of a project.

Conversation Points:

• How do you keep track of your design failures?
• Why is it important to capture the reason for design failures?
• Should the reasons behind a failure be private or public?
• Is a book of design mistakes as important as a portfolio?

Thanks for all of your responses!

Related Posts:

Part 2 of The Importance of Failure for Designers

Part 3 of The Importance of Failure for Designers