The Loop that Drives
Call me loopy
I have a reputation for focusing on the Design Thinking Loop. The Loop brings an amazingly subtle perspective on what it means to be relentless in innovation. I do not think it is accidental that the simple act of Designing, Building and Running software aligns nicely with the design thinking Observe, Reflect, Make loop. Building is obviously Make, and how convenient is it that when you Run your software you use a whole range of Observability tools to understand how the solution performs. In a good SDLC loop you Reflect on those observations to Design the next release, and around we go. The other beautiful thing about viewing your work as a loop is that it creates convenient places to hang continuous improvement activities. Try to close significant loops with meaningful retrospectives that are given the chance to update the process before the next iteration begins. Let’s get into it, what does it mean to Loop through the Observe, Reflect, Make process?
Observe
During a workshop we are frequently reminded that during the Observe portion of the exercise that we are Observing as Individuals. This means we are not discussing it with the team, but more importantly it means we are looking inward at our own experience. Some people struggle with how to make observations, and I encourage them to think about what they have heard about the topic. What have they seen? What do they think about that, and how does it make them feel. Those are all valid observations, and will add value to the discussion.
When making observations, it is very important to remember that as engineers, we are not our users. This is why user research is so critical to the design process, and a great example of how design thinking extends outside of the workshop environment. Interestingly enough, there are three specific design thinking tools that I think of as being primarily observational tools and they are each focused on different styles of user research. The Interview, the Contextual Inquiry, and the Cognitive Walkthrough - each of these tools requires a design thinker that is being very intentionally observant. What does it mean to be intentionally observant? It is a heightened sense of situational awareness that is focused on a user, or on a sponsor who is representative of a community of users. Examples of being intentionally observant include: using open ended questions in an interview, observing a note pad used during a contextual inquiry, and taking note of how long it takes a user to find a button on a prototype in a cognitive walkthrough.
Observing application performance and user actions should be built into your process. These observations should foster reflection by the team when designing the next release. The ability to make adjustments and shift plans based on observed reality is a critical component of a roadmap management process and a key driver of keeping the design-build-run loop small and agile.
Reflect
During a workshop, after some time to observe, the team will come together to reflect on the observations and find valuable information. I do not think that this word was chosen lightly, as it is very comfortable to tell a colleague that you need to reflect on that information for a while before making a decision. The idea of taking time to talk things through, to find meaning and value in an observation before taking action, becomes almost second nature in a design thinker. Reflection becomes a yes-and exercise that can generate outcomes that incorporate a whole range of perspectives. Finding these ideas and recognizing the patterns that are exposed when you consider them all together is the true key to innovation.
It is important to note that reflection done properly can not be done alone. If you find that you have discovered something significant, then you should probably conduct a playback and allow the team to reflect on this new piece of information before anyone makes any decisions. Observational work such as Interviews or Contextual Inquiries should have playbacks with the team and reflect on what was observed during research, then the team can make adjustments as needed.
During workshops, there is a temptation to lead reflection. If you are facilitating reflection, focus on the ideas on the table, it’s best to lead with questions, let the team summarize or clarify language.
Make
During a workshop, or for very small loops, you might not be making much… maybe a decision, maybe a diagram, but after any reflection you should have a way to take action based on the information or patterns that were discovered. Give form to an idea, it’s always better to show something than it is to describe it. Prototypes can be quick and simple, the proverbial pen and napkin sharing of an idea. It also helps to remember that everything is a prototype for the next version, if we know we’re going to replace it with something better we build just what we need now while establishing a well thought out “sacred geometry” for things to come.