Monthly Archives: January 2019

Design Thinking

Design Thinking Needs No Single Definition

Leave a comment

I just wrapped up my second year teaching a course on design thinking for the San Jose State University iSchool.

Years after promoting the idea that LIS education programs should pay more attention to design thinking – and even going so far to suggest that our profession would benefit from a Masters of Library Design – it has been an incredible experience to develop this course from the ground up and to have the privilege to share what I’ve learned about design thinking with our next generation of librarians.

One of the challenges in preparing for the second year was making a decision about how to define and present the design thinking process. Knowing that my students would be encountering a number of different definitions and presentations of the process, I thought it might be best to decide on one definition and make that the standard for the duration of the course.

Perhaps a bit controlling but at least it provides a consistent approach to learning design thinking, as well as a standard platform for conversation. I also let the students know that they should use the course to either define design thinking on their own terms or identify a definition that most resonates them. What definition, graphics or examples, I asked them, would best enable them to explain design thinking to their colleagues? So while I maintained a somewhat strict approach to defining design thinking for the course, I made it clear that after the course, students were free to develop their own way of defining and describing it.

I suppose that’s why this article resonated with me. Even when a group of experts were asked, there was no exact agreement or consensus on the definition of design thinking. While some might take that as a sign that design thinking shouldn’t be taken seriously if it can’t be consistently defined, I tend to see it differently. The author says as much in writing:

One of the greatest strengths but also weaknesses of design thinking is that there is no single, widely used definition for it. This flexibility in meaning is beneficial because it encourages challenge, exploration, and inquiry, and allows people to morph the concept to their needs.

In the post “What is Design Thinking, Really? (What Practitioners Say)” by Sarah Gibbons, she describes research involving interviews with industry experts. They were asked a series of questions, such as “What do you think of when you hear the phrase “design thinking” and “How would you define design thinking?”. I tend to see lack of a single definition more strength than weakness precisely because if offers the opportunity to bring some individuality to it – though there are clearly some constraints to which any definition would need to conform.

The responses reflect the lack of consensus among these experts in their description and definition of design thinking. But the responses do reflect the core process and activities involved in design thinking. There is a breakdown of the terms and phrases used by experts to define design thinking. Some, such as “problem-solving”, “process” and “human-centered design” are totally expected. They are organized into multiple thematic categories such as “uses” and “specific steps”.

While the experts had no shared definition, their responses point to three shared ideas that come closest to a common understand of what constitutes a design thinking approach:

*It is a process for problem solving (though I prefer to emphasize it’s about problem finding).

*It is a change in the way you think, a mindset shift, about how you do your work.

*It is a toolkit, a set of strategies and approaches for solving a problem.

Gibbons suggests that there is also a scaffolding effect that shapes how we define design thinking. It starts with defining it as a process, then evolves into a mindset and then becomes the toolkit used for applying design thinking in practice. That strikes me as a good way to define design thinking when I explain to someone coming to is as a blank slate.

You should make of it what you will to rethink or refine your own way of defining design thinking. I will point my future students to this article as a way of demonstrating why they need to ultimately shape their own definition while being true to the value of design thinking and the process they will make their own.

I’m glad to have discovered this article because I plan to adopt the (six) process steps it identifies – and make that the new standard for my course. It’s quite close to what I already use, but I think it will be an easier set of terms for students to remember – and it has a solid diagram to illustrate the process. This article is a solid addition to the core literature of design thinking.

Experience Design, User Experiences

A Jobs-To-Be-Done Lens As a Path to Better Experience Assessment

Leave a comment

For many patrons, library interaction could be reduced to a “jobs-to-be-done” methodology. If that is the case, how could librarians best leverage that perspective to design services that are “get-jobs-done” focused and then measure how well jobs-based outcomes are met?

We’d need to start with a “jobs-to-be-done” approach – at least for the jobs where community members have a well defined sense a perfectly completed job.

Community members’ most common library job-to-be-done that requires an on-site visit is to borrow a specific print book or physical media item. Online, the acquisition of a specific e-book, journal article, streaming video or other collection item is a frequent job-to-be-done. For these types of jobs, most library users will take a self-service approach. If our systems are useable and predictable, reasonably fast and efficient, the result ideally is a “job completed perfectly”.

Currently, I would venture to state that most libraries operate on an approach that is more hopeful than capable of consistently delivering on perfectly completed jobs. In the absence of assessment methods that tell us the extent to which our systems – basically “us” since we create/deliver and maintain them – succeed, fail or fall somewhere in between.

In his article “Measure Customer Progress Using a Proven Jobs-To-Be-Done Methodology” Tony Ulwick gives a concise explanation of how a customer would determine the success, on multiple levels, of their job completion. It can be stated as simply as this:

Customers believe they have made progress when they are offered a means to get a job done better and/or more cheaply.

Ulwick suggests using a “progress” lens through which to examine the job-to-be-done approach. He then elaborates on different dimensions on which customers determine progress.

  • Get part of a job done better.
  • Get an entire job done without having to cobble together disparate solutions.
  • Get a job done with a single product.
  • Get multiple jobs done with a single solution.
  • Get a job done more cheaply

Using a library example, consider a community member who has a book title and wants to obtain it. If the library holds the book and it’s readily available, a single product, the library catalog, should get the job done easily. But locating the book is only one part of the job. Another system, such as a self-checkout machine is needed to complete the job. Things get exponentially less simple if the library doesn’t have the book. The community member might stop there and head to Amazon, but if their job demands free access then that member may be willing to pursue an interlibrary loan. How many members, outside of the experienced ones, will even know where to start that process?

When designing user experiences, I think it would be of value use the jobs-to-be-done lens to approach services as those that can be designed with user progress in mind. That is, the community member should easily determine if their job exemplified progress. Another set of job-to-be-done, the ones we know require more intensive support, should be designed with the expectation for human intervention and relationship building. That way libraries could maximize their limited human resources to prioritize where staff enable community member progress.

Another consideration is that community members sometimes come to the library not knowing exactly what job they need to get done – and expect to receive help from library staff to figure out what it is. I’m thinking of students I’ve encountered who have an assignment in hand but are not quite sure what they are supposed to do. You might say their job-to-be-done is simply to find out what to do, but there are times when librarians can get beyond just a task or transaction – in fact that’s what we should hope to do most of the time.

Ulrich also shares ideas for how measure if customers are making progress towards getting their job done. He suggests using three dimensions: speed (how fast), reliability (consistently free of errors/failure) and efficiency (little or no waste of time or resources). Too often community members use their library and there is no measurement of their success in completing their job-to-be-done.

I like the “Outcome-Driven Innovation” process that Ulrich recommends. I can envision a fast and easy online assessment where library customers would use a sliding scale, from “Job Not Completed” to “Job Completed Perfectly” to identify how well the library allowed them to accomplish their job. Outcomes are based primarily on speed, reliability and efficiency, but their could be human dimensions as well (e.g., friendliness, welcoming approach, compassion, etc.).

I can imagine asking community members to complete a quick, sliding scale assessment (likely conducted on a tablet or via a follow up email) for measuring how well the library supported the completion of their job-to-be-done. It would not provide an in depth explanation, but would at least be a start to achieve a reliable and consistent method to measure how often we enable community member progress – or fail to live up to their expectations for achieving it.