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.

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.

What about the API Economy?

Do you find your head spinning at the emergence of the industry term, “API Economy?”   You might wonder what role your organization and company should play…once you figure out exactly what it is…

One definition comes from an IBM RedPiece entitled, “The Power of the API Economy.”

The API Economy is the commercial exchange of business functions, capabilities, or competencies as services using web application programming interfaces (APIs). APIs drive the digital economy and companies that do not embrace the API economy will be left behind.”

The API Economy is key to accelerating value, improving business performance, and extending your business services and goods to the widest possible audience. Making sure your company is easy to do business with and creating paths to new business opportunities is why the API Economy signals a new business reality. Companies that seize this opportunity will differentiate themselves and grow.

The way I explain the API economy is that the web and mobile computing make it very easy for businesses to share valuable components.  Application programming interfaces are somewhat like the doorway to using a component.  The components themselves can be data, logic or full services; they can be very small or large – just something that provides value to others.  Providing other institutions with access to these valuable assets can become a competitive differentiator, or provide a new source of revenue.  Consuming assets made available by other companies can accelerate innovation, again providing competitive differentiation.  Simply put, sometimes it’s better to buy than build.

Playing in the API Economy requires understanding what data, logic and services your company has that provide value to others, and also understanding what data, logic and services other companies have that provide value to your organization.  This determination does not happen effectively in a vacuum.  It must involve business leaders so that APIs offered and consumed align with the overall business strategy.

An analogy is that I make a really good potato salad.  If I offered access to my potato salad, other people could forget about searching for recipes, gathering ingredients and learning to make potato salad.  They would just use the API into my potato salad service, saving time and delivering really good potato salad whenever they needed it.  I would make money from no longer protecting my potato salad as a family exclusive offering but rather give many people access to my valuable potato salad assets.  However, offering my potato salad as an API based service does not make sense because I have no desire to enter the food service business – it doesn’t align with my business strategy.

Sometimes data, logic and services that your company wishes to offer into the API economy are tightly coupled in legacy solutions in a way that makes sharing them difficult.  The IT organization may need to undertake a de-coupling effort to separate user interfaces, data, storage, and business logic so even very granular sized assets can be made available.   This doesn’t mean an IT organization needs to re-engineer every asset.  Rather, any re-engineering efforts should occur aligned with business priorities associated with making the asset available for internal or external consumption.

Continuing the potato salad analogy – maybe someone really likes just my potato salad dressing and would like just that component.  If I wanted to offer my potato salad services, I might serve a larger market if I could de-couple some of the ingredients at a more granular level.  I might make much more money selling my potato salad dressing in addition to selling the fully integrated potato salad service.

This might sound like a daunting task when it’s your IT and business assets versus my potato salad recipe, but there are many software products and gateways that help make business assets accessible.  The place to start is not with the tooling but with understanding the business strategy and objectives as well as having an exploratory discussion regarding internal and external assets that should either be made accessible to others or that your company should start accessing.  Making the wrong assets accessible or accessing the wrong assets just helps accelerate doing the wrong thing for the business.  It’s better to use the agile concept of pausing to understand the highest priority assets to access and to make accessible, and keeping the works in progress to a small number during the re-engineering phase.

For the CIO, understanding what IT assets, business logic and business data exist is critical to entering the API Economy successfully. If your company plans to offer APIs versus just consuming them, then providing an infrastructure that supports unpredictable workload spikes without impacting performance is also extremely important.  The capability to measure and bill for API-based service consumption also needs to be established, unless your company sees value in offering API-based access to assets on a charitable basis. 

Hopefully if your head was spinning it no longer is regarding the definition of the “API Economy.”  Also, hopefully, you don’t see participating in the “API Economy” as a daunting effort.  Part of the “API Economy’s” beauty is the component-based approach, making use of other organizations’ good work versus requiring your organization to shoulder the majority of efforts. 

And if none of this makes sense but all this talk of potato salad is making you hungry, maybe just drop me a note to get my recipe….