Personal Design Thinking

I'm currently reading the book Design the Life You Love by Ayse Birsel. The book takes a look at Design Thinking and applying it to your own life. It is based on the success that the author has had as a product designer.

The book takes you through a four-step process; Deconstruction, Point of View, Reconstruction, and Expression. She uses examples from her own design career to help illustrate the steps of the process. 

In the Deconstruction phase, there are exercises to break your life down into some of its pieces. For example, in one exercise you start with the number of areas including family, work, friends, and hobbies and break those down into more meaning for you. It's really just a mind map that you're trying to create. 

The section on Point of View is meant to help you try to look at things differently. For example, she talks about how Steve Jobs looked at a rice cooker with a magnetic power cord and thought that would be a great idea for a laptop. The idea is taking something in one context and moving it to another context. 

Reconstruction is taking the pieces that have been identified and put them back together in a different way. 

Finally, Expression is about how you externalize this effort. There are some different ideas including vision letters and vision maps. 

This really is a workbook that you want to spend time on every day to go through the exercises. I would not recommend getting the book in an electronic format, it is much more practical to have the physical book that you can draw in as you go through the exercise. There are some exercises that involve drawing, mind mapping, etc and throughout the activities, you want to go back and review earlier work. 

I'm working through the last section, so I don't know how it will all turn out, but I have had some valuable insights. The book is laid out logically and it does get you to think. 

In closing, there is a quote from Ralph Caplan, author of By Design;

When it comes to life,
There is no such thing as design
There is only redesign

Empathy and the Sponsored User

Empathy is an important attribute in Design Thinking. In order to solve our customer's problems, we really need to understand them. We need to walk in their shoes. But there's a limit to how far we can take this. We can spend hours talking to an astronaut, but we will never truly understand what it's like to walk in space.

Agile has this idea of the Product Owner, but you don't see much written in agile about empathy. One approach that can help you get past the empathy hurdle mentioned above is to find a key user (or users) to be part of your team. Some organizations call this a Sponsored User, the organization leading the project sponsors this person't participation in order to get their direct input into the product.

The sponsor user becomes one part of the multi-disciplinary team. Their input is important, but it isn't the only input. While they may understand the customer perspective, you need to balance all the project constraints, especially the time and cost it may take to implement some of the sponsored user's ideas. Don't lose sight of your minimal viable product (MVP) in trying to make the sponsored user happy.

You may also have more than one sponsored user, depending on the breadth of the solution you are trying to provide. If your current release has two or three major themes or epics, you could have a different sponsored user for each epic. Contrast this to the idea of having a single product owner responsible for the overall solution.

So when empathy isn't enough, make the user part of the team in order to keep the direction of your product moving the right way.

Henry Ford and Design Thinking

By LibertyGroup25 (Own work)

Henry Ford pioneered many of the ideas that are now commonplace in business, including ideas used in Design Thinking. He has been quoted as saying "If you ask people what they want, it would be a faster horse." This hits on the design thinking principle of divergence. You need to understand what problem you are solving before coming up with a solution. Henry Ford wasn't solving a problem around horses, he was solving a transportation problem.

I was in a design thinking workshop and we did an exercise where first we were asked to draw a door bell. Then we were given a problem in a different framing, we were asked to draw a way to know if someone was at the door. The second set of drawings were much different. A doorbell would have worked, but by reframing the question, many other solutions came out.

Another Henry Ford quote is "you can have any color, as long as it's black." On the surface, this might not sound very customer friendly, However, this response was due to the solution to another problem. When he was developing the production line for the Model T, he was challenged in the painting step. He found all paint colors took to long to dry, except black. By only offering black, he was actually fixing a bottle knock in his process...applying the theory of constraints as it were.

Next time you're working on a solution to a problem, spend a few minutes and think about the framing of the question. Can you change the question in order to expand you possible solutions?

Are You Experimenting?

I came across another interesting idea in Change By Design. It was presented as Toyota's ideas around training and had 4 principles:

• There is no substitute for direct observation
• Proposed changes should always be structured as experiments
• Workers and managers should experiment as frequently as possible 
• Managers should coach, not fix

This idea of experimenting caught my attention. So often as I'm designing a solution for a customer, they want to try to get the perfect solution first time out of the box. When they don't know what perfect is, they struggle to make decisions. I can recall one client, after 3 weeks of developing a complex interface, others looked at it and we went through another 3 weeks revising it. This was all in development, the real end users didn't have a chance to try it out. No experimentation at all, just managers trying to guess what was needed. No direct observation.

This is just one example of something I see a lot of. Not being open to experimenting. Smart organizations are figuring it out though. The push for a DevOps approach and employing Microservices is a move in the right direction. With DevOps, we can deploy something and if it doesn't work, we can have a different solution out in weeks or maybe months, not quarters or years. With microservices, we get away from the monolithic applications and have a bunch of small, independent components. If one doesn't work quite right, the whole system doesn't fail.

So how open is your organization to experimenting? Are failures discouraged or recognized as the first step towards success? Are you trying to get everything perfect or do you recognize that everything is a prototype, even if it's in production?

Divergence and Convergence

There's another idea from Tim Brown's Change by Design I thought was worth writing about. It's the idea of divergence and convergence.  Early in a design project (or any project), we want to collect lots of ideas. This is divergence...creating lots of possible choices. Linus Pauling, winner of 2 Nobel prizes, stated "To have a good idea, you must first have lots of ideas." If you're writing user stories, don't try to limit story creation. Just because a story is written doesn't mean it will be delivered but if it's never written it definitely won't be delivered.

Brown provides some ideas for generating ideas

• Have an overarching purpose. I think of Design the Box when I hear this.
• Involve the whole organization (or whole project team, sounds like agile again).
• Don't discard ideas just based on who came up with them
• Allow people room to experiment. This sounds like a spike to me. 

Now we get to convergence; making our choices. This is where we take a look at all our ideas and decide which ones to move forward with. It's grooming the backlog, prioritizing the stories, and throwing away the ones that don't fit our goal. Again, we should use our vision to help make these decisions. 

Brown points out the design is both art and science. The divergence is about being creative. The convergence is about using more analytical tools to make decisions. Also, don't think of this as a linear process...you may go back and forth between the two steps. For example, you just finished an iteration and are getting ready to plan the next one. You may have a divergent step and you synthesize the information generated in the iteration and demonstration but you need to quickly move to convergence to pick the user stories for the next iteration. 

Design Thinking and Constraints

I've been reading the book Change by Design by Tim Brown. It's part of my overall interest in design in general. I have found a number of interesting ideas in the book so far, and I'm not even half way through it. 

One concept had to do with constraints. Anyone that has worked much on projects know that constraints are a big part of it. He talks about three aspects of constraint; feasibility, desirability, and viability. 

Feasibility is looking at whether or not something can be done in the near future. 

Viability is looking at whether or not it's sustainable from a business model perspective. 

Finally, desirability of course is will it be something that people want. In design thinking you want to take into account all three of these aspects as you're working on a project.

As I think back to projects that I have had that have been either successful or not successful, I can see how all of these play into a project's success or failure. 

On an actual project, we can test for feasibility by doing something like a spike, a short test to prove out if the idea will work.

Viability may be a bit harder to show on a project. It will take other supporting input such as market research to prove the approach is a sustainable business model. This is probably best done before you go to far in the project.

I think there's a very strong tie between desirability and how agile projects work. It's that whole idea of working closely with your users to truly understand their needs. 

I've seen other ties between design thinking and the agile approach. I'll have more to say on the future blog post.