Semantic Software Design

Chapter 4. Design Thinking

There exists a designerly way of thinking and communicating that is both different from scientific and scholarly ways of thinking and communicating, and as powerful...

L. Bruce Archer, Whatever Became of Design Methodology?, 1979

Design Thinking is a method to help incite innovation, creativity, and purpose when you design solutions for customers. In this chapter, we transition to outline a repeatable process for applying Design Thinking within your organization as a semantic software designer (perhaps “creative director in technology”).

Why Design Thinking?

When a customer approaches you for a technical solution, you need to start somewhere. Having a method for problem solving will help you map the territory in a repeatable way that gives customers and other stakeholders confidence and comfort as you guide them through a process. Using the tenets of Design Thinking specifically will help to improve your chances of coming up with the a creative, customer-focused solution.

We start with Design Thinking because we who have been called enterprise architects and have purview over the entire enterprise will see many problems as design problems. It helps encourage you to be focused on the customer, the solution, and a meaningful outcome, rather than focused on your own internal activities, classifications, and documents. This is the hallmark of the creative, effective semantic designer.

Further, we begin with Design Thinking because so many problems can be viewed as design problems. Consider these questions:

• If you deeply consider with empathy who will use this solution and how, and how it fits into their context, are you, in a sense, redefining the customer?

• What is the optimal organization to support the creation and ongoing maintenance of this solution? What process can be designed to optimize its delivery, before the solution gets to the user?

• How will you consider the schedule itself such that you align various competing factors for the creation, launch, and delivery to again optimize the experience?

• How will the solution be managed?

What these all suggest is that although we tend to consider only the technical solution as the object of design, there are many contributing aspects of our work that can benefit from approaching our problems as design problems. The organization, solution, production, delivery, and supporting infrastructure and maintenance all can be optimized by approaching them as design problems. With our purview across the enterprise in solving customer problems, we must consider the wide variety of stakeholders, the design of the business, the application, the data, and the infrastructure; you and your team must thoughtfully design all these areas of a technology solution and the supporting business.¹ Design Thinking offers a set of guidelines and practices to help you do this, which we examine now.

Exploring Design Thinking

In the 1950s, professors at MIT and Stanford began exploring creative methods for industrial design. The term “design thinking” originated in 1965 with L. Bruce Archer’s book Systematic Method for Designers. This term and evolving related practices were later popularized by Palo Alto design consultancy company IDEO in the early 1990s, which based its early work on the Stanford curriculum. Given the breadth and long history of these concepts as they have routed through academe and industry, different adherents might not always agree on what Design Thinking precisely refers to. What we discuss here represents my particular take on it, as a curated collection of many of these different approaches to Design Thinking, refined over time with use in the field.

The primary steps in Design Thinking are illustrated in Figure 4-1.

Figure 4-1. The Design Thinking process

Principles

Before we dive into each of these steps in the process, let’s start with the principles that design thinkers can generally agree on:

Human-centricity

Design Thinking is perhaps first about empathy. It asserts that all designs exist to be used by a person to advance some human cause. Keeping the human user, their context and conditions, their different abilities, cultural differences, and their being situated in a social context is what makes great design relevant, useful, and delightful.

Showing, not telling

Instead of talking about the design, find creative ways to express it. Architects often present UML diagrams and written documents. These can be critical. What if you had to present your design on the back of a cereal box and make punchy illustrations of what its main features are and why it’s exciting? If you had to present your architecture in the form of a story, how would you do that?

Clarification

One of my old mentors once told me, “leaders make the uncertain certain.” How can you take the big, messy, wild-and-woolly problem space and clarify and refine it down to its key elements? How can you capture the essence of the solution and convey its impact succinctly?

Experimentation

Use a bias toward action. Even though it’s called Design Thinking, it’s really about doing. As in iterative software development, how can you start quickly making a prototype to get in front of people so that you can improve it with their feedback?

Collaboration

The orchestra wouldn’t sound as good if it used only the horn section; by combining the wind instruments, the string instruments, and other types, you can do richer, more sophisticated things.

Diversions

If you search the web, you’ll find other representations of Design Thinking principles, such as a focus on process. Process is very important to success, and much of this book is devoted to how you can turn your work into a repeatable (almost standard) process to make a compelling product with an architecture practice. However, I purposefully leave out the principle of “process” as stated by the d.school because to me, your own internal process, while important to know and follow as reality allows, is not interesting to the end user. There are no cookies for strict adherence to the dictates of a methodology as long as you understand it and employ it properly to achieve the desired aim. After all, it is about creativity, so it strikes me as a bit antithetical, especially given that there is no single, received, universal process here. Second, it is critically important to keep your eyes on the goal of creating something of use to someone else—overemphasizing process can result in finding yourself engaged in exciting-seeming, but ultimately fruitless, debates over schools of thought and niggling about your own internal activities in ways that don’t benefit your customer.

Now that we understand the basic tenets of Design Thinking, let’s walk through the process for how you can apply it as you approach architecture and software design.

The Method

The method is about following the path illustrated in Figure 4-1. We explore each of these steps and how to practically apply Design Thinking in your own architecture shop here.

Design Thinking Is Context for Applied Architecting

The method outlined here is about viewing the world as a set of problems and opportunities and that designing your approach to both with the subsequent goal of designing a solution is broadly applicable. It is intended to be used as a context and foundational viewpoint for implementing the specific areas of “architecture” and design outlined in the remainder of this book.

Define the problem

The first step is to understand the problem that has been presented. Here, you clarify the need.

It’s important, at least eventually, to refine the problem or challenge down to a single statement of need: one sentence that illustrates the purpose or goal. This will be useful later for internal marketing purposes, for getting others enlisted in your cause.

The second step is to define what success looks like. What are your acceptance criteria (to borrow the term from Agile) for having created something truly special that’s an obvious improvement?

Make observations

This step is about discovery. After you know what the problem is that you’re solving, and you know what success looks like at the end, you start your investigation.

Determine the users

The first question to ask yourself is, “Who are the stakeholders in this solution?” You might be surprised. Spend some time on this step to generate a real list. For example, if you’re designing software for use in a hotel, it’s easy to think of the front-desk person. But what about the concierge, housekeepers, groundskeepers, bellmen, doormen, managers, and so forth? Also consider the programmers who must maintain this software, your colleagues in the Network Operations Center monitoring its performance—are they not users, too? They might not be external paying customers, but they will use your software from a different point of view and for a different purpose. But deciding that they are part of your observation set or not will certainly modify your solution.

Defining whom you’re actually solving a problem for is a potentially difficult exercise in set theory, but it is a critical first step to getting the scope right. If you leave out roles, you will have an inadequate observation set and leave things out. Push yourself to list as many roles of different user types as you can.

Observe users’ actions

Now you can go about understanding their relation to this product or service or space. How do they try to accomplish the task today? What tools do they use? Why do they care about it? What parts are painful to use? What opportunities can you afford them to gain some new super power?

The primary way to do this is by observing them in action and then writing down what you see. Is there an existing tool they use to get their jobs done that you can watch them interact with? Try to shadow them during daily use. If you’re designing a new cash register for a restaurant, can you follow a few different waiters to see where it works and doesn’t work well for them?

Of course, it’s important to talk with existing customers, too. They often will reveal things in conversation that are difficult to observe. You also want to note any disparity between what they say and what you observe.

Ask yourself the following questions:

• What do they say about their pains using the product? Is there a feature that they know they miss having?

• What workarounds do they have to implement to get past some inadequate aspect of the tool? A popular workaround in software is writing down passwords on a sticky note because they’ve become so complicated, and we all have so many of them that they can be difficult to remember. Newer computers allow you to login with a biometric feature such as a fingerprint, which is one way of making that problem go away.

• Are there aspects to its use that they never use? Why is that?

Jumping to Conclusions

At this stage, it’s very tempting and easy to begin interpreting what you see and forming ideas immediately about the solution. You presumably have some familiarity with the problem space or you likely wouldn’t be involved in designing the solution. You could design the whole thing in your head, perhaps. When that’s the case, it’s easy to bring your own biases and preconceived notions about the solution, which skips the entire point of Design Thinking.

To be more creative and innovative, you want to be free of those biases and be focused on the user. For now, simply observe people and record your observations, not what you think about them. We’ll do that in a bit. For now, even though it doesn’t feel like you’re doing much, simply recording user interactions in the manner of a courtroom stenographer without judgment is actually an important step toward creating something innovative.

Consider at this stage different kinds of uses. When you watch customers actually using the product, does that match what they say about how they use it, or is there a cognitive disconnect? For example, do they say keyboard shortcuts are very important to them, but then they don’t actually use them?

“I Use It Every Day”

So that you can record as many accurate observations as possible and create a comprehensive list, it’s important to consider at this stage that sometimes “use value” can be a slippery subject. People don’t always use a product as intended, or as we might expect them to. For example, once upon a time we had an architect at our house who was inquiring about how we used our space. He turned his attention to our swimming pool and asked with some skepticism if I ever actually used it. I quickly replied, “Yes, I use it every day: I look at it.” Maybe I didn’t swim in it very often (the obvious purpose of a pool, which implies it’s not useful to me), but in a hot desert with a bright sun and lots of brown sand, it was very important to my sense of well being to see the cool, blue water. The idea is to be clear on the actual value users might derive, beyond a perceived or ostensible value.

Create personas

Now that you have your list of users, you can create personas. A persona is a fictional representation of a person who is a stakeholder or user of your solution. When you do this, you are essentially creating a character who is a composite of users that you interviewed and the observations you made about their goals and challenges.

One important trick here is to chose “extreme users.” It’s obvious and easier to focus on your mainstream or typical users. But this is a mistake. Extreme users are the experts, the people with a lot of knowledge about the problem space and existing solutions. They tend to have a lot at stake in their success using your product. They are highly knowledgeable on the subject and therefore very opinionated and vocal. They tend to be the ones who push the boundaries.

Early Adopters

Extreme users tend to have the most elaborate workarounds for things that aren’t how they want them. In this way, in a sense, extreme users can become “early adopters” of a product or function that doesn’t quite exist yet. Consider this example: in 1998, eBay was known mostly for selling regular household objects for a few dollars. The idea of selling a Ferrari for tens of thousands of dollars on the auction site then would have been flagged as suspicious behavior. But eBay took note, and instead of shutting it down, it launched a new division: eBay Motors.

Extreme users might also be people of very different ages. For example, Apple did well when making the iPad because it is usable not only by the initial obvious affluent market of technophiles, but also by three-year-old children. But Apple failed here when designing machine learning algorithms for facial recognition, which best worked only on white males.

In listing your candidates to create as personas, you want to consider the typical activities they go about in a day.  Then, write down their goals: what is it that they want to do. This is not about what they want to do with your software. It is guaranteed with 100% certainty that they do not want your software in any way. They want to do something else that your software helps them do. They don’t want Photoshop and they don’t want to “edit and crop photos”: those are merely tasks they perform on the way to getting what they want. They don’t want to “use” your music streaming software: they want to relax and be entertained after a long day. They don’t want to arrange their web templates: they want to effectively market their products. No goal that is important to a person is about software. Sometimes, if we have a fun car and it’s a beautiful day, we might take pleasure in driving just for driving’s sake. There are many things pleasurable in their own right. But I submit that no human ever said: “I think I’m in the mood to use some software. Oh, any old application will do. I just want to use software for a bit.”

As you see the list of activities and goals you’ve discovered, you can group them. These can potentially translate later into security roles as you do detailed architecture work.

A persona is a document that has the following attributes:

• A name. Create a name for this representative person.

• An age, occupation, and education.

• Fictional details. Create a few lines of personal details in order to bring the character to life and make them more vivid and real. Include their desires, interests, and limitations. Given the impression of a story behind this person, you can better focus on designing for real humans.

• A picture.

The document should likely fit on a single page and might look like Figure 4-2.

Be sure to include multiple personas, each representing a different set of user goals, cultural backgrounds, and ages.

Figure 4-2. A sample persona template (icon via FlatIcon, Creative Commons)

Value Proposition Design

There’s a wonderful book on the subject of determining the value proposition of your solution called Value Proposition Design (by Alexander Osterwalder et al). Although not strictly focused on Design Thinking, the book offers templates and a method to help you define and refine how to create products and services that matter to customers and help build your business.

Now you can use your collection of personas to form insights about what should be done to create your solution.

Form insights

An insight is an interpretation of your own, based on the facts. You “see into” the objective data and make refutable assertions about what might be the case about the situation. You can see patterns in the data and decide on some theme and notice correlations. You assign meanings among the interplay of signs that are beginning to form your semantic field.

An insight is nonobvious. It reveals something about the object that others might not have noticed or with which they might have an argument.

It is a moment that combines the raw data you’ve collected so far, and now you start to draw conclusions about what a solution looks like. You are not forming a design of the software. Resist that temptation. Yes, deadlines are tight, and we can be eager to skip steps and head right for the coding. But if we do that, we miss a lot.

You are simply making another list of your conclusions.

Now you can create a Customer Journey Map. This is a diagram that illustrates the steps your customers go through when they engage with your organization. It’s a helpful tool for documenting a user’s path through a service. You might think of it like a storyboard in films: the director creates a cartoon strip of drawings that makes sure everything is laid out properly and the sequences are right before they spend money doing expensive shots, particularly when there are limited opportunities, such as when failing daylight might affect the continuity of the shot.

These maps help you to identify the interactions that cause users most pain. (They also serve as a great starting point in building a process map later if you get into Business Process Modeling with BPMN to do business process reengineering using Lean Six Sigma. If that sounds fascinating, just wait until we get to Chapter 6.)

Mapping the Customer Journey

There’s a great online tool at LucidChart that’s easy to use and helps you make your own Customer Journey Maps.

They allow us to visualize the emotional state of users and highlight the flow of the customer experience, including the good, the bad, and the ugly of their interactions. This helps us to focus our opportunities for improvement.

Frame opportunities

First, you need to transform those insights into opportunities. What are things you could do to creatively improve their interactions and experience?

Now you reflect on your collection of ideas, and pick one category to go with. For now, you can pick just one that you will pursue for prototyping. Of course, you still have this material if you want to return to it later.

Generate ideas and refine solutions

Your goal at this step is to transform the ideas into a solution. This is really a brainstorming phase. To brainstorm well, you must defer judgment, encourage wild ideas, build on the ideas of others, stay focused on the topic, be visual when possible, and go for quantity.

Now you can do a fun exercise. After you’ve picked your specific opportunity, you then draw the idea on some poster board. Draw four frames, or quadrants. Give it a name at the top and then a brief description and state what user need is addressed.

Then draw stick figure–type drawings into each of the four quadrants representing how people would use and benefit from your solution.

Try prototypes

Here you create named experiments.

When I visited the Google campus in Mountain View many years ago, I was given an early demonstration of Google Glass. I was fascinated to learn that in the Google X Labs, the first prototype was built in a single day, using a backpack, a laptop, a tiny projector and a piece of plexiglass with some hanger wire. The idea was that because the developers had started with thinking empathetically about the user, they quickly refined their priorities to conclude that it was a potential showstopper if people felt too awkward having the web projected into their glasses that way. So that’s a boundary that they wanted to explore right away.

A Prototype in a Day

You can read about the prototype development process for Google Glass at geek.com.

Build prototypes quickly that reflect a certain aspect of the product you know might be problematic or require an adjustment for your users.

To do this, ask yourself, what could be done for only $100 in just one day to test the premise of your solution? Remember, you’re not testing anything like what a solution might be in the real world, you’re testing the premise. In the case of Amazon Alexa, for example, the premise is that users would want to have a robotic assistant based primarily on voice interaction. You don’t even need to build anything at all to play through a variety of scenarios with that idea; you just need to take regular interactions, such as playing music, checking the weather, or booking a hotel room with yourself and another person speaking the parts, with one of you playing “Alexa.”

When you have landed upon the prototype that works best, the Design Thinking party is over, and you can then set about creating it as a full-fledged solution to move to production and delivery.

In the next section, we see how to put these ideas into practice with workshops to implement Design Thinking at your organization.

Implementing the Method

Much of the existing literature about Design Thinking assumes that you are designing a physical object for use out in the real world, or that if your realm is software, that it only would be of interest to user experience/user interface (UX/UI) designers. One assertion of this chapter is that the creative architect will find much here to fruitfully adopt and adapt, even when what you’re focused on is not the UI, but the architecture for a data streaming application or cloud services or an API. Indeed, if many problems we face are design problems, I urge you to consider how to apply these concepts even without a UI or, indeed, even without software.

You should not consider the stages within Design Thinking as purely sequential. Your approach should be iterative, and the real world will end up necessitating that anyway. It’s helpful to go back and revise or reconsider earlier decisions in light of new understandings.

Design Thinking as Fractal Within Your Structure

A fractal is a geometric figure in which each constituent part has the same structural or statistical dimensions as the whole. Because Design Thinking is a way of approaching design with an empathetic, collaborative, and iterative mindset, it is applicable whenever you are creating artifacts of architecture design. That is, it is not only to be considered in isolation regarding your software product, and I do not present it here as operating solely in the domain of user experience or user interface design.

In a larger project, use Design Thinking at each stage, not just once up front. You can employ an adaptation of the method when it’s time to consider the business, application, data, and infrastructure aspects. The insights you generate can be incorporated entirely within each stage of a broader process while also observing how it operates at a higher level toward that broader goal of delivering the complete software product.

To begin your Design Thinking work, collect these tools:

• An easel with large conference room–sized paper

• Sticky notes

• Markers

• Dot-shaped stickers to vote with

Pull together a workshop, and depending on the scope of your challenge, you might need a couple of days or a few weeks.

First, frame the challenge. You do this by having everyone write on sticky notes what they think the problem might be. You should do this quickly, in a matter of five or seven minutes. Then put all of the sticky notes on a paper and discuss. People will typically see different emphases in the problem space, and you can use these to ensure that you have properly framed the problem.

Then, move on to focusing on the user, the customer. Determine who they are, and figure out how to make observations in the field. After you have this list, you’ll likely break and then move on to scheduling how to make those observations with real people.

Now you have collected your data such that you can create personas.

Using the raw data from your field journal observing users as well as interview notes and personas, you are ready to form your insights. Time for another workshop!

Give people time to review the collected material. Then, in this workshop, try to get participants to start assertions with “I wonder....” This encourages them to exercise their thought process, to venture a thought that is perhaps incomplete but could be built upon, and to go beyond what they feel sure they already know. Otherwise, people tend to repeat their own entrenched views or to speak in platitudes so as to avoid conflict.

As they did before, have each person generate as many insights as they can, writing them down on sticky notes. Then, have the facilitator collect and place them altogether on the paper boards with markers so that everyone can see them together.

Now you can begin to see patterns in the insights. Eliminate true duplicates, being careful to discuss if any subtle differences in the apparent duplicates are relevant and shouldn’t be lost. This is a consolidation step. Next, you can discuss and elaborate on what was meant. Ambiguity is just fine here and is in fact something to be encouraged. Be sure people are not designing the solution yet.

Group the insights into different categories.

Then, you can use the dot-shaped stickers to vote on the insights you’ve formed that make it to the posters. These are stickers of different colors that you can get at a hobby or office supply store. Each person voting has their own color so that everyone can trace back who voted for what in case further conversation is needed. The voting serves only to narrow down the focus on the most pressing concerns, setting the stage for the next step.

Now, you’re ready to discuss what opportunities might be suggested by the insights. Again, you’re not designing the solution (say, your software product) at this step. You are generating ideas on what could be new and how you might help your users mitigate the pains and realize the gains.

Now you can repeat the sticky-note voting process to again narrow toward a focus. You’ll draw on your storyboard for your identified solution at this point.

At this point, you’re ready to brainstorm solutions, describe them, and vote on them.

Now you leave the workshop with a slate of work, go build your prototype, and again go out into the field to test it with real people. This, of course, will be an iterative process of refining your prototypes until you have something buildable that you can deploy.

Throughout the process, be sure to honor the following principles:

• Focus on users’ experiences with an emphasis on building empathy

• Allow, accept, and encourage ambiguity

• Tolerate mistakes or oversights

• Regularly reset expectations about what stage you’re in throughout the process and restate the near-term goals

With all of this work, you will have come up with a terrific solution that has an excellent chance of being well designed for solving real people’s problems and giving them usefulness and hopefully delight and maybe even joy. You’ll have done that by seeing much of the world and experiences as design problems, by grounding your approach firmly in framing the problem properly, and by harboring strong empathy for your user.

Summary

This chapter introduced Design Thinking, the principles and practices, and how you as a creative architect can put it to work. If you’d like to learn more about Design Thinking, check out these additional resources:

• See this Harvard Business Review article.

• See this in-depth case study on how Design Thinking was used to improve processes for veterans at the Bureau of Veteran Affairs.

• IDEO Design Kit. This website offers case studies and a wealth of practical resources to assist you in taking a Design Thinking approach in your next project. This includes a field guide and a variety of courses that you can take.

• The d.school at Stanford. The university’s design school website offers some material about Design Thinking in broader application, such as designing space and furniture. Of course, that’s the original purpose of Design Thinking anyway! Check out its Bootleg Toolkit to help support your process.

In the next chapter, we build on this Design Thinking approach. Keep it in your back pocket throughout the book: many problems and opportunities across the entire technology enterprise can be helped when framed as design problems with these tools.

¹ A fun aside is that our approach to design can be expanded to help design your career, your life itself, if you shift to think of them as design problems.