Translate

Monday, December 12, 2016

A quick introduction to Design Thinking...



Last week I judged senior engineering university students’ computer science projects.  I found myself wondering how Design Thinking might have been used in their projects because some were written assuming all users would be like them, university students.  The thought kept crossing my mind that my shopping behaviors have changed dramatically since my university days.  Thus, what “wows” me now probably differs from what “wows” many university students.

Design Thinking is a powerful method for creating impactful solutions that connect with varied human experiences.  The method evolved within software engineering because user experiences drive usage which in turn drive revenue.  This subtlety is important.  Understand the human experience and how it can be improved.  Let that guide what goes into the development plan. 

To use Design Thinking, you first must master a cycle used extensively: diverge, cluster, re-mix, converge and playback (DCRCP).  Warning: it requires a lot of sticky notes. 

Here’s a quick overview of that cycle.

Diverge: Typically when a group brainstorms, after 15 minutes or more of debate, the group may have agreed upon a single idea. In contrast, when team members diverge, after 15 minutes, you will likely have several dozen ideas.  Diverging simply involves all team members, without chattering or collaborating, writing ideas on sticky notes and putting them on a common collection point such as a flipchart.    

Cluster: At this point your flipchart might look a bit chaotic.  However, as you look at the sticky notes scattered across the page, you will start to notice similarities.  Physically move the sticky notes into clusters of similar ideas.

Re-mix: Some clusters might seem so strongly connected that they should be joined.  Or, some clusters might seem too broad and need to be sub-divided.  During the re-mix activity, make those adjustments as appropriate.  Again, physically move the sticky notes.

Converge: Now that your team’s ideas have been clustered and re-mixed, make a sticky note that accurately conveys the ideas upon which the team converged.

Side note: cluster, re-mix and converge activities should take about 15 minutes.  Thus, in about 30 minutes your team expresses and organizes many ideas.  Meanwhile, using traditional group brainstorming methods, you might have a few agreed upon ideas, or you might still be debating.

Playback: The final step in this cycle is to playback what the team did.  Playbacks occur within the team as well as with other teams, sponsor users and even sometimes people independent of the project.  The objective of playbacks is to confirm understanding, secure buy-in and gain feedback.

So, how can this DCRCP cycle help build strong solutions?  Here are some Design Thinking exercises that help quickly express and funnel ideas until a few high impact items are identified.

Define stakeholders.  Use the DCRCP cycle to define stakeholders. Note: Stakeholders aren’t just users.

Define personas.  Rather than talk about “users” in generic terms, Design Thinking defines “personas” by sub-dividing stakeholder groups based upon various common human experiences within that sub-group.  As I mentioned at the onset, something like a grocery shopping app should take into consideration the differences between my shopping habits as a professional versus those of a university student.   

Again using a sticky note, draw a picture of someone that represents a certain stakeholder sub-group, give the person a name and put the note on the board.  After diverging to define numerous personas, take a moment for each team member to describe a bit about the persona before clustering them, etc...  

Using the Agile principle of reducing works in progress, choose a few stakeholders to proceed with.

Empathy mapping.  For each persona, using the DCRCP cycle, identify what this persona might be thinking, feeling, saying and doing.  This helps the team connect with the human experience of this sub-group. 

Using the Agile principle of reducing works in progress, choose a few key personas to proceed with.

Map scenarios.  For each persona, identify a common scenario that persona encounters.  Then, identify the key phases in the scenario.  For example, if you are trying to improve the grocery shopping experience, a common scenario is weekly grocery shopping. The scenario map for someone like my mom who stayed home and spent a lot of time cooking meals differs from the scenario map for someone like my daughter who lived in a large city and didn’t own a car.   Key phases for someone like my mom might be planning menus, figuring out needed ingredients,  assembling the shopping list, reviewing coupons and sales, filling the cart, checkout, putting groceries in the car, going home and putting groceries away.  However, for someone like my daughter, they might be assemble a shopping list, walk to store, fill the cart, checkout, walk home, put groceries away.

Using the DCRCP cycle, for each persona’s scenario, identify at each phase what the persona is thinking, feeling, saying and doing.  This will start to identify high impact solutions you could create as you see points of confusions, frustration, or inefficiency in the scenario map.

Ideation: Now that the team has insight into a few key personas, use the DCRCP cycle to define big ideas.  These should be broad and conceptual versus writing detailed product specifications. 

Prioritize Ideas and Choose Hills:  To adhere to the Agile concept of limiting works in progress, you can use various methods to prioritize the ideas.  One prioritization method gives everyone an allotment of two different colors of dots.  One color represents the importance of implementing the big idea and the other represents the feasibility of implementing it.  Every team member votes using their dots.  Votes are tallied and the ideas are then placed on a two-dimensional matrix with one axis going from least to most feasible and the other going from least to most important.

Things that are high impact and highly feasible are no-brainers and go into the project plan.  Just go get them done as it seems it is an easy thing to do.  Things that are low impact and difficult, discard.  It’s too much work for too little payback.  The other two sets of ideas require discussion and consideration.  Often they fall into two categories: very feasible but not highly impacting and highly impacting but also difficult to do.  The first group can provide a utility function that perhaps is mass consumed.  The second group is a risk but can provide huge competitive differentiation. 

From these ideas, the team defines 3 hills that they want to conquer.  The hill definition is simply what are we going to do for whom and what is the “wow” aspect. 

Storyboarding:  In some cases it is appropriate to create a storyboard that defines the persona’s new experience.  This provides an outlet for your cartoon drawing capabilities because you will draw pictures of the persona’s anticipated new experience.

The result of using Design Thinking is a prioritized approach to rapid delivery of incremental high impact solutions that connect with users’ human reality. 

Earlier this year, I served as a Peace Corps and IBM Corporate Service Corps Volunteer, part of a team that helped a Ghanaian social enterprise, TECHAiDE, architect, design and prototype an educational device for use in developing economies.  Using Design Thinking, in one month we were able to not only architect, design and prototype the device; we wrote the curriculum and helped define or refine several core business processes.  Now, a few months later, the product is launched in its pilot.  If you’re interested in learning more about that project, click here to read my blog about it.

Despite its coding origins, I use Design Thinking on all sorts of projects, not just coding ones.  For example, I’ve used it to design classes and create consulting offerings. 

This is a very quick overview of Design Thinking.  If you’re interested in someone leading you through a Design Thinking workshop, let me know.  I am happy to help you.

Sunday, January 31, 2016

A word on "Agile"

When I was a kid some people called me "agile" because I could sit straddled on the floor, reach forward and put my head on the ground, and stay there comfortably just like it was natural.  In my day, calling me "agile" was mild "hater-speak" for "It hurts me just to look at your contorted body."  But now, agile is an "in" term and with no connotations tied to "haters" unless we consider innovative geeks to be "haters."

In some circles agile is a way of life but amongst skeptics, it can inspire groans and rolled eyes.  Whoops, look who's talking like a "hater" now... but I digress.  

I will confess that I see value in agile methods, and no it's not so I can still be called "agile" though my current physical flexibility level declares victory if I can get on the floor and successfully get back up.  The first premise of agile is to slow down, have fewer works-in-progress so that you actually get more done.  So, what it actually connects with is my practical side.

To slow down and have fewer works-in-progress, you need to do solid strategy and planning to have a prioritized list of projects based upon their impact towards achieving your business goals.  Side note: If you struggle prioritizing your projects based upon their overall impact to business goals, I happen to know someone who writes a CIO blog and has filed for a patent on a methodology to do just that. 

This notion of prioritizing based upon business goals supports another premise of agile which is to start with the end in mind.  Again, it's about being practical.  Let's clear away the politics and emotion and focus on what we're trying to accomplish.

The list of projects forms the "backlog" or input queue that feeds the "scrum" process.  This is a process whereby the projects are subdivided into "sprints" typically tangible accomplishments that can be achieved in about 30 days.  This supports another premise of agile, in that perfection is the enemy of "good."  A series of vignettes released in shorter time spans usually results in more stuff getting done than if you wait to ship or use anything created until it's perfect.  It also tends to do two other things: feed the current "news feed" hunger for almost continuous stream of new things and raise team morale as the team sees tangible things steadily moving from the "to-do" to the "done" pile.

The process is a little like having a holiday cookie baking party.  You have one oven, limited baking utensils, a small team of helpers, many recipes/projects and it can be chaos unless you prioritize which recipes/projects are getting first dibs on mixing bowls and the oven.  You sub-divide your prioritized recipes into batches/"sprints" and each batch/sprint yields something tangible and useful and if it's cookies, probably even delicious. 

The process is very similar when using agile for any project; it's just that an agile development sprint is typically 30 days not 10-12 minutes like with a batch of cookies.

There's another aspect of agile that differs from the holiday cookie baking party in that sprints have daily "stand-ups."  The notion is that the daily status meeting is brief to the point it can be held standing up; hence, the name.  During the daily stand-ups, just ask three questions:
  1. What did you do yesterday?
  2. What will you do today?
  3. What, if anything, is blocking you?
For folks who love hour or longer status meetings, this might shock your system.  But, most people I know eschew status meetings if at all possible.

Periodically the team has retrospective meetings to adapt the process if needed. They can also adapt the prioritization of projects based upon feedback and changing market dynamics.

Successful use of agile requires some foundational values: respect, trust, openness, and courage.  The focus shifts from tools and process to individuals and interactions, from mountains of documentation to living documents, from rigidly following "the plan" to agile adaptability to change.  And, thankfully, it does not require placing your head on the floor whilst doing the splits.  It's much simpler than that.  Give it a try.