Over the past few months I’ve shifted from a product-centric mindset to a service-centric mindset. My focus used to be on building products that help people accomplish a task or goal. That meant I would try to understand the problem to solve, who it’s being solved for, and then design digital products to solve that problem.
But as I’ve grown as a designer, become a manager, and seen Optimizely move into the enterprise market, I’ve realized that a lot more goes into making a product successful than the product itself. Companies often offer additional services to make customers successful.
A service is a touchpoint or system provided by a company to fulfill a need. A touchpoint is how someone uses a service — a website, phone line, ticket kiosk, and so on.
Most digital products, for example, have additional online properties to help customer be successful, like a knowledge base. Companies can also provide non-digital services, such as a support line customers can call or email.
Even though a service may not have a visual interface, they can still be thoughtfully designed. To make good decisions about how these services work, you still need a solid understanding of your users and their goals. This is what product designers do when designing a product, with the only difference being the final deliverable is not a visual interface.
Shifting to a service mindset makes it obvious that new technologies that have invisible UIs, like Alexa and Operator, can be thought of as services and designed just like any other service. In its simplest form, design is the act of making thoughtful decisions. Having empathy and understanding a user’s goals, motivations, and context help designers make thoughtful decisions. These activities apply to services and invisible UIs just as much as creating visual interfaces.
On top of that, all of the products and services that a company offers its customers need to work in concert with each other. This means that it isn’t enough for each product and service to be well-designed on its own — they also need to be designed to seamlessly work together to make customers successful. Doing this also requires having a broad understanding of your customers.
When I had a product-centric mindset I was aware of the different touchpoints, but I hadn’t put much effort into designing them all as a cohesive, interrelated experience. Customers may use the knowledge base and email support while using the product, but that’s for the support team to manage. “I’m just going to make the product great because that’s all that customers need to be successful,” I used to think. I’ve since learned that isn’t true. It takes more than the product itself to make customers successful.
Learning about the discipline of service design has helped me connect all the different touchpoints customers use into one unified framework. Everything is a service — products included. And they can all be thoughtfully designed by using the core skills designers already have. By doing so, customers will have a better experience with your products and services, which will make them more successful, and that will ultimately make your company more successful.
If you’re interested in learning more about service design, these books and articles have taught me a lot:
I recently saw Sol LeWitt’s Wall Drawing #273 at the SF MOMA, which really stayed with me after leaving the museum. In particular, I like that it wasn’t drawn by the artist himself, but rather he wrote instructions for draftspeople to draw this piece directly on the walls of the museum, thus embracing some amount of variability. From the museum’s description:
As his works are executed over and over again in different locations, they expand or contract according to the dimensions of the space in which they are displayed and respond to ambient light and the surfaces on which they are drawn. In some instances, as in this work, those involved in the installation make decisions impacting the final composition.
Sol LeWitt’s Wall Drawing #273
This embrace of variability reminds me of the web. People browse the web on different devices that have different sizes and capabilities. We can’t control how people will experience our websites. Since LeWitt left instructions for creating his pieces, I realized I could translate those instructions into code, and embrace the variability of the web in the process. The result is this CodePen.
A six-inch (15 cm) grid covering the walls. Lines from corners, sides, and center of the walls to random points on the grid.
1st wall: Red lines from the midpoints of four sides;
2nd wall: Blue lines from four corners;
3rd wall: Yellow lines from the center;
4th wall: Red lines from the midpoints of four sides, blue lines from four corners;
5th wall: Red lines from the midpoints of four sides, yellow lines from the center;
6th wall: Blue lines from four corners, yellow lines from the center;
7th wall: Red lines from the midpoints of four sides, blue lines from four corners, yellow lines from the center.
Each wall has an equal number of lines. (The number of lines and their length are determined by the draftsman.)
As indicated in the instructions, there are 7 separate walls with an equal number of lines, the number and length of which are determined by the draftsperson. To simulate the decisions the draftspeople make, I included controls to let people set how many lines should be drawn, and toggle which walls to see. I let each color be toggleable, as opposed listing out walls 1-7, since each wall is just different combinations of the red, blue, and yellow lines.
The end result fits right in with how human draftspeople have turned these instructions into art. The most notable difference I see between a human and a program is the degree of randomness in the final drawing. From comparing the output of the program to versions done by people, the ones drawn by people seem less “random.” I get the sense that people have a tendency to more evenly distribute the lines to points throughout the grid, whereas the program can create clusters and lines that are really close to each other which a person would consider unappealing and not draw.
It makes me wonder how LeWitt would respond to programmatic versions of his art. Is he okay with computers making art? Were his instructions specifically for people, or would he have embraced using machines to generate his work had the technology existed in his time? How “random” did he want people make these drawings? Does he like that a program is more “random,” or did he expect and want people to make his wall drawings in a way that they would find visually pleasing? We’ll never know, but it was fun to interpret his work through the lens of today’s technology.
In 2016, I read 22 books. Only 3 of those 22 were fiction. I had a consistent clip of 1-3 per month, and managed to finish at least one book each month.
Highlights include:
The Laws of Simplicity by John Maeda: the first book I read this year was super interesting. In it, Maeda offers 10 laws for for balancing simplicity and complexity in business, technology, and design. By the end, he simplifies the book down to one law: “Simplicity is about subtracting the obvious, and adding the meaningful.”
David Whitaker Painting by Matthew Sturgis: I had never heard of the artist David Whitaker until I stumbled on this book at Half Price Books in Berkeley. He makes abstract paintings that combine lines and colors and gradients in fantastic ways. The cover sucked me in, and after flipping through a few pages I fell in love with his work and immediately bought the book. Check out his work on his portfolio.
Libra by Don DeLillo: a fascinating account of all the forces (including internal ones) that pushed Lee Harvey Oswald into assassinating JFK. The book is fiction and includes plenty of embellishments from the author (especially internal dialog), but is based on real facts from Oswald’s life and the assassination.
NOFX: The Hepatitis Bathtub and Other Stories by NOFX: a thoroughly entertaining history of the SoCal pop-punk band NOFX as told through various ridiculous stories from the members of the band themselves. It was perfect poolside reading in Cabo.
Org Design for Design Orgs by Peter Merholz & Kristin Skinner: This is basically a handbook for what I should be doing as the Head of Design at Optimizely. I can’t overstate how useful this has been to me in my job. If you’re doing any type of design leadership, I highly recommend it.
The Gift, by Lewis Hyde: a very thought-provoking read about creativity and the tension between art and commerce. So thought-provoking that it provoked me into writing down my thoughts in my last blog post.
I finally finished “The Gift,” by Lewis Hyde, after reading it on and off for at least the last 4 months (probably more). Overall I really enjoyed it and found it very thought-provoking. At its core it’s about creativity, the arts, and the tension between art and commerce — topics which are fascinating to me. It explores the question, how do artists make a living in a market-based economy? (I say “explores the question” instead of “answers” because it doesn’t try to definitively answer the question, although some solutions are provided).
It took me awhile to finish, though, because the book skews academic at times, which made some sections a slog to get through. The first half goes pretty deep into topics including the theory of gifts, history of gift-giving, folklores about gifts, and how gift-based economies function; the latter half uses Walt Whitman and Ezra Pound as real-life examples of the theory-based first half. Both of these sections felt like they could have been edited down to be much more succinct, while still preserving the main points being made. This would have made the book easier to get through, and the book’s main points easier to parse and more impactful.
There’s a sweet spot in the middle, however, which is a thought-provoking account of the creative process and how artists describe their work. If I were to re-read the book I’d probably just read Chapter 8, “The Commerce of the Creative Spirit.”
The book makes a lot of interesting points about gifts and gift-giving, market economies, artists and the creative process, how artists can survive in a market economy, and the Cold War’s affect on art in America, which I summarize below.
On Gifts and Gift-Giving
Gifts need to be used or given away to have any value. Value comes from the gift’s use. They can’t be sold or stay with an individual. If they do, they’re wasted. This is true of both actual objects and talent.
Gift giving is a river that needs to stay in motion, whereas markets are an equilibrium that seeks balance.
Giving a gift creates a bond between the giver and recipient. Commerce leaves no connection between people. Gifts foster community, whereas commerce fosters freedom and individuals. Gifts are agents of social cohesion.
Gifts are given with no expectation of a return gift. By giving something to a member of the community, or the community itself, you trust that the gift will eventually return to you in some other form by the community.
Converting a gift to money, e.g. by selling it on the open market, undermines the group’s cohesion, fragments the group, and could destroy it if it becomes the norm.
Gift economies don’t scale, though. Once it grows beyond the point that each member knows each other to some degree it will collapse.
On Market Economies
Market economies are good for dealing with strangers, i.e. people who aren’t part of a group, people who you won’t see again. There’s a fair value to exchange goods and services with people outside the group, and no bond is created between people.
Markets serve to divide, classify, quantify. Gifts and art are a way of unifying people.
On Artists and the Creative Process
Artists typically don’t know where their work comes from. They produce something, then evaluate it and think, “Did I do that?”
To produce art, you have to turn off the part of your brain that quantifies, edits, judges. Some artists step away from their work, go on retreats, travel, see new things, have new experiences, take drugs, isolate themselves, and so on. The act of judging and evaluating kills the creative process. Only after a work of art is created can an artist quantify it and judge it and (maybe) sell it.
Art is a gift that is given to the world, and that gift has the power to awaken new artists (see above, gifts must keep moving). That is, an artist is initially inspired by a master’s work of art to produce their own. In this way, art is further given back to the world, and the cycle of gift-giving continues.
Each piece of work an artist produces is a gift given to them by an unknown external agent, and in turn a gift they pass on to the world.
Artists “receive” their work – it’s an invocation of something (e.g. “muse”, “genius”, etc.). The initial spark comes to them from a source they do not control. Only after this initial raw “materia” appears does the work of evaluation, clarification, revision begin. Refining an idea, and bringing it into the world, comes after that initial spark is provided to them by an external source.
Artists can’t control the initial spark, or will it to appear. The artist is the servant of the initial spark.
Evaluation kills creativity – it must be laid aside until after raw material is created.
The act of creation does not empty the wellspring that provided that initial spark; rather, the act of creation assures the flow continues and that the wellspring will never empty. Only if it’s not used does it go dry.
Imagination can assemble our fragmented experiences into a coherent whole. An artist’s work, once produced, can then reproduce the same spirit or gift initially given to them in the audience.
This binds people by being a shared “gift” for all who are able to receive it. This widens one’s sense of self.
The spirit of a people can be given form in art. This is how art comes to represent groups.
The primary commerce of art is gift exchange, not market exchange.
How Artists Can Survive in a Market Economy
The pattern for artists to survive is that they need to be able to create their work in a protected gift sphere, free of evaluation and judgment and quantification. Only then, after the work has been made real, can they evaluate it and bring it to market. By bringing it to the market they can convert their gift into traditional forms of wealth, which they can re-invest back in their gift. But artists can’t start in the market economy, because that isn’t art. It’s “commercial art,” i.e. creating work to satisfy an external market demand, rather than giving an internal gift to the world.
There are 3 ways of doing this:
Sell the work itself on the market — but only after it’s been created. Artists need to be careful to keep the two separate.
Patronage model. A king, or grants, or other body pays for the artist to create work.
Work a job to pay the bills, and create your work outside of that. This frees artists from having to subsist on their work alone, and frees them to say what they want to say. This is, in a sense, self-patronage.
Bonus way: arts support the arts. This means the community of artists creates a fund, or trust, that is invested in new artists. The fund’s money comes by taking a percentage of the profits from established artists. This is another form of patronage.
But even using these models, Hyde is careful to point out that this isn’t a way to become rich – it’s a way to “survive.” And even within these models there are still pitfalls.
Soviet Union’s affect on art in America
In the 25th Anniversary edition afterword, Hyde makes the connection that the Cold War spurred America to increase funding to the arts and sciences to demonstrate the culture and freedom of expression that a free market supports. A communist society, on the other hand, doesn’t value art and science since they don’t typically have direct economic benefit, and thus doesn’t have the same level of expression as a free market. The end of the Cold War, unfortunately, saw a decrease in funding since the external threat was removed. This was an interesting connection that I hadn’t thought about before.
Final Thoughts
All in all, a very thought-provoking book that I’m glad I read.
Update 3/23/18: I created a Skillshare class to teach you how to implement a Discovery process at your organization.
In my previous article, I described how we transformed our Agile development process at Optimizely to include research and design by implementing our own flavor of Discovery kanban. This process gives designers and researchers space to understand our customer’s problems and explore solutions before we commit to shipping new features. In this article, I’ll go a level deeper to describe all the stages research and design work moves through during the discovery process.
Updating work on the Discovery kanban board
Background
The Discovery kanban board is based on the double-diamond model of design, which visualizes the design process as two connected diamonds. The first diamond represents understanding the problem, and the second diamond represents solving the problem. Diamonds are used to communicate that work alternates between divergent phases, in which ideas are broadly explored, and convergent phases, in which ideas are filtered and refined. Peter Merholz, a founding partner of UX consulting company Adaptive Path, has a nice overview of double diamond design.
The diamonds represent different kinds of work, with defined inputs and outputs, so I adapted each diamond into a kanban board. A kanban board is simply a series of stages, represented as columns, that work moves through, with acceptance criteria that dictate when items move into each stage.
The first kanban board is Problem Understanding, where we gather information to understand and frame the problem. The second kanban board is Solution Exploration, where we take the output of Problem Understanding and solve the specific problem we identified. Together, they make up Optimizely’s Discovery kanban process.
Overview of Discovery kanban at Optimizely
Problem Understanding
The goal of the Problem Understanding phase is to understand, refine, and frame the problem so it’s concrete and solvable. The input is a problem area to study further, and the output is a deeper understanding of the problem (often in the form of a report or presentation). The output either feeds directly into the Solution Exploration backlog, or it’s general knowledge that benefits the company (e.g. helps us make a strategic decision).
Work on this board moves through 5 columns: Backlog, To Do, Researching, Synthesizing, and Socializing.
Problem Understanding kanban board
Backlog
“Backlog” is just a bucket of problem areas and pain points. It isn’t prioritized, and anyone can put a card up on the board. There’s no promise that we’ll work on it, but it’s at least captured and we can see what people are thinking about.
The cards themselves are typically written in the form of a question to answer, e.g. “What metrics do people want to track?” But sometimes we just write a problem area to study, e.g. “New metrics & metrics builder.”
To Do
Each week, we take items out of Backlog and move them into “To Do.” We typically prioritize items based on how big of a problem they are for customers (with input from the product vision, roadmap, and company priorities), but this isn’t a strict rule. For example, we may need some data to make a strategic decision, even if it isn’t the “biggest” problem.
After an item has been prioritized, we write up a research plan to answer the question. This includes choosing a research method(s) that’s best suited to answering this question. There’s no prescribed format for the research plan, but at a minimum it specifies what question we’re answering and the research method to use.
The research method could be a qualitative method, such as customer interviews or contextual inquiry, or a quantitative method, such as sending a survey, analyzing server logs, or querying the data warehouse. For some problems we use a combination of different methods.
Researching
Once a research plan has been agreed upon, work moves into the “Researching” stage. This means we execute the research plan — customer interviews are scheduled, a survey is sent out, analytics are analyzed, and so on. This stage is divergent — we go broad to gather as much data related to the problem as we can.
Synthesizing
After gathering data in the Researching stage, work moves into the “Synthesizing” stage. We analyze the data we’ve gathered for insights and, hopefully, a deeper understanding of the problem. This stage is convergent — we are filtering and focusing the data into concrete takeaways and problems to be solved.
Socializing
Once the research has been synthesized, it moves into the “Socializing” phase. The bulk of the work is done, but the outcome is being shared with the team or company. This takes the form of meetings, a presentation, a written report, opportunity assessment, or whatever format is appropriate for the problem being studied. At the very least, a link to the research plan and the data captured is shared with the team.
Sometimes we learn that a problem is especially complicated and the research plan wasn’t sufficient to understand it. If so, we may do more research (if this problem is important enough), or just make the best decision we can based on the data we do have.
After studying a particular problem, the work either ends there (in the case of things like personas or data to inform product strategy), or it turns into a problem for design to solve. In the latter case, work moves into the Solution Exploration backlog.
Solution Exploration
Once we understand the problem, we can start designing solutions to it. We track this work on the Solution Exploration board (a.k.a. the second diamond in double diamond design). A problem may have UX challenges to solve, technical challenges to solve (i.e. is this feasible to build?), or both. The output of the Solution Exploration phase is a finished solution to build. The solution is either a complete UI, such as mockups or a prototype, or a technical solution, such as a technical design doc or a technical prototype, which can be implemented in a production environment.
In this phase, work also moves through 5 columns: Backlog, To Do, Exploring & Thinking, Iterating & Deciding, and Ready to be Built.
Solution Exploration kanban board
Backlog
Just like in Problem Understanding, work starts life in the “Backlog.” This is a big pool of problems to solve, and anyone can add items to it. But once again, just because it’s in the backlog doesn’t mean we’ll work on it — it still needs to be prioritized.
To Do
Each week we prioritize items in the Backlog and move them into “To Do.” This means we have a well-formed problem, informed by data (typically generated in Problem Understanding, but may come from other sources), that the team will design a solution to. For most problems, we formally write out a what the problem is, why it’s worth solving, who we’re solving it for, and the scope. (View the template on Google Drive).
Writing out the problem before jumping into solutions ensures the team is aligned on what we’re solving, which prevents wasted work and changing scope after a project begins. It also surfaces assumptions or incomplete data we may have, which would mean we need to go back to Problem Understanding to gather more data.
Exploring & Thinking
After a problem definition has been written, work moves into the “Exploring & Thinking” stage. This means we’re exploring solutions to the problem. This could be sketching, prototyping, building technical proof-of-concepts, researching potential libraries or frameworks, writing technical design docs, or whatever method is best for exploring possible solutions. This stage is divergent — a broad range of possible solutions are being explored, but we’re not filtering or refining any particular solution yet.
Iterating & Deciding
Once a broad range of solutions have been explored, we move into the “Iterating & Deciding” stage. This means potential solutions are being evaluated and refined. Tradeoffs and approaches are being discussed with relevant groups. This stage is convergent — ideas are being refined into a single, finished solution.
There isn’t strict criteria for whether an item is in “Exploring & Thinking” or “Testing & Iterating.” The creative process is somewhat chaotic and people often switch between an “exploring” and “refining” mindset throughout a project. But there’s typically an inflection point at which we’re doing more refining than exploring. The exact column work is in is up to the person doing it.
Having 2 columns may sound unnecessary, but it’s useful for two reasons. First, it helps communicate where in the creative process work is (especially early stage vs. late stage). This helps designers, engineers, and PMs have better discussions about the solutions being explored. Second, it encourages people to separate divergent thinking from convergent thinking. It’s easy to just go with the first idea, but that’s rarely the best solution. By encouraging exploration, we increase the odds that we’ll choose the best solution.
Ready to be Built
After we’ve iterated enough we’re left with one finished solution that’s ready to be built and shipped to customers. A “finished solution” is one for which all edge cases have been thought through, it’s been vetted by relevant parties, and there are no major questions open that would slow down development. Finished solutions are in the form of mockups or a prototype, if a UX solution, or a technical design doc or proof-of-concept, if a technical feasibility solution. The finished solution then moves into engineering’s backlog, where it gets prioritized against all the other potential work to be done.
Together, the Problem Understanding and Solution Exploration kanban boards make up Discovery kanban. The definition of each column may sound prescriptive, but it’s actually a suggested process to follow. Work doesn’t always move linearly through each column, and we aren’t sticklers about meeting exact acceptance criteria to move work forward. The important thing is that we’re working together to solve our customer’s biggest problems, ultimately increasing customer value and business value.
Since implementing this process we’ve gotten better at prioritizing the biggest customer problems to understand, have space to explore solutions to those problems, and are regularly shipping work to customers. No process is perfect, but we’re always trying to improve how we work in an effort to consistently ship great products to our customers.
Sol LeWitt’s Wall Drawing #273
Updating work on the Discovery kanban board
Overview of Discovery kanban at Optimizely
Problem Understanding kanban board
Solution Exploration kanban board