Lately, we’ve been able to watch him take his first steps to being a normal “human”. Having barely started his adventures into crawling, Tristan feels the need to spend his time standing up leaning against things more than anything. Crawling is just a mechanism for him to go from standing on one piece of furniture to the next. This is no surprise to me, as I walked myself at 7 months old. Now, we’re hoping that Tristan won’t walk THAT soon, but I wouldn’t be shocked to see him taking his first stand alone steps in the next month or so.

The biggest transition has been the eating of real food. The doc says the food doesn’t really do anything for him besides get him used to eating food rather than milk. Feeding him his baby food is always an adventure though, but not in a bad way. Tristan getting his lunch or dinner is generally a very audible experience, filled with grunts, coos, and squeals. Some of this is probably my fault, as I try to get him to say ‘Nom Nom Nom’ when he is eating. Hopefully, one day he will say these three wonderful words while eating and I know it will be followed by me laughing my head off.

The first half of this crazy year is over, and the next is well under way. Hopefully, I’ll find more time to write about being a dad and the adventures of my son. But, as I’ve quickly learned being a dad takes A LOT of time.

P.S. This post would have been done 10 minutes ago, but Tristan crawled over and we got into a tickling match. I won for those interested.

I’ve been asked to be speak at the Innovation Camp to talk briefly on why User Experience Design is so important for start ups, and to explain how Prototyping can help lead to a better product. Prototyping is a process of exploration, that eventually leads to a vision of your product or service. During the course of my presentation, I’ll cover the importance of prototyping, how divergent thinking is key to the start of any prototyping process, and practical tools and methods that can used to bring your vision to life. I hope to see you later this month at St. Louis Innovation Camp!

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

2010 New Year’s Resolutions

• Find a mentor to help round out my underdeveloped design skills
• Design and Build a website
• Present on UX at a conference again
• Write more on this blog
• Organize a charity donation for Childhood Leukemia in honor of my cousin Lily
• Create an online outlet to write short stories
• Take my wife on a great vacation
• Attend interactions, IA Summit, and IDEA
• Try to teach my son something valuable (Going to be a challenge since he will be an infant/toddler)
• Solidify the UX Community in St. Louis (If interested in helping please let me know)
• Speak on UX at a local college or university
• Write more for Johnny Holland
• Learn from my numerous failures in 2009
• Cut the number of Twitter friends that I haven’t met down
• Learn how to be a better amateur photographer with my Nikon D40

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.

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

Just to put everyone’s fears at easy, Loki has not made a single aggressive move towards Tristan. If anything, he tries to lick him to death every chance he gets. The poor dog does get very jealous though, since the baby has taken up residence in one of his favorite places. Our laps. Over the last couple of months, we have gotten a bit creative and found a way to fit them both in our laps. This does make getting up in any kind of hurry a challenge however.

Tristan is about to take over the last bit of what Loki might see as his territory in our house. He has gotten to the age where getting some belly time is becoming more important, and has even begun to roll over. For 3 years, the floor has been the one area of the house that was strictly Loki’s. If we laid down, he immediately knew you wanted to play. Discouraging this urge to play with anyone that’s on the floor is going to be our next big step with properly integrating the dog and the baby.

Another observation we’ve made with Loki is his need to ensure his scent is present on any of Tristan’s stuff. Normally, this means rolling around on his blankets or cloths. Sometimes Loki takes it to the extreme and sleeps in Tristan’s rocker, Boppy, and most recently his car seat. As of last night, I don’t think Loki will be attempting to car seat again. While attempting to get comfortable, he rolled the car seat off the couch, and tumbled across the room. Bear in mind that during the fall and subsequent rolling, he was ‘safely’ tucked inside. Needless to say, it freaked the poor dog out and we don’t think he will be looking to take a nap in the car seat any time soon.

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

Creating an Accordion Navigation

The image shown above was the base state of the accordion navigation I built. All of the screen elements presented are drawn rectangles rather than any control that comes along with inherited behavior. The base state is the foundation for any animation a designer wishes to built to mimic interactive behavior. From this starting state, a designer can create iterations of the screen and tie the various states together. What happens when switching between the various states is completely taken care of by Blend, very much like the tween functionality in Flash. Below are screen shots of the two other states I created, and the States panel. Notice one of the defined states returns the accordion to the base state, I am unsure if this is necessary but it worked for me.

The SketchFlow Animation Panel works exactly that same way as states, but only allows for a single animation flow. If it’s desired that the interactive aspects of the prototype be conditional, it’s required to use the States aspect of Blend.

Rollover Effects

Providing a rollover effect is a common need for prototypes. The SketchFlow Animation Panel is perfect for exhibiting this type of behavior. On the ‘Countries’ page, the sketched picture circles can be navigated by rolling over the right arrow. Here is a look at the SketchFlow Animation Panel that allows for this type of behavior.

Drag and Drop

Adding the Drag and Drop behavior is as simple as adding a property to a control. With this property added, it’s possible to place the control anywhere on the screen. Blend adds the proper code necessary, behind the scenes, so a designer can concern themselves with exploring the behavior rather than programming it. As you can see from the screenshot, there are many behaviors available that can be added to any control.

Blend is a powerful prototyping tool given that you find yourself in a WPF/Silverlight development environment. It provides the same benefits that many other prototyping tools have for other development environments. So which tool should a designer use? It depends. It all depends on the type of environment you find yourself in and personal preference. Hope you have enjoyed my exploration of Blend and if you find yourself using it one day please share your experiences.