Category: Process

In Search of the Design Mind

Everyone gets to have their dream job at least once in their career.

Several years ago I had mine, working with a team of internal UX design consultants for Fortune 50 company. Our mission: survey the best thinking in the field of user-centered design, spend three months deciding what was useful and what was not, and formulate our own approach to UCD that was simple, efficient, and pragmatic enough to work within the time and resource constraints of a large high-tech enterprise. We then evangelized this approach, which we called Information-Driven Design, throughout the corporation, and consulted with project teams all over the world to help them find big unmet user needs and solve hard design problems. Many innovations were spawned as a result.

The foundation for our home-grown approach was the simple premise that human-computer interaction can be thought of as an information management problem. We demonstrated that designing a successful product was essentially a matter of properly distributing responsibility for “information requirements” between the user and the product in a way that maximizes the strengths and minimizes the weaknesses of each.

The inspiration behind this approach can be traced back to a passage from Don Norman’s The Design of Everyday Things:

“Between us and our machines, we could accomplish anything. People are good at the creative side and interpreting ambiguous situations. Machines are good at precise and reliable operation. Unfortunately, this is not the approach engineers have followed in reacting to advances in technology. Instead, they’ve adopted a machine-centered view of life: machines have certain needs, humans are adaptable. Give machines priority, technologists’ thinking goes, and tailor human operations to fulfill the requirements of machines.”

Information-Driven Design was a systematic approach to exposing machine-centered thinking and its manifestations in product designs, followed by a reimagining and redesign of the product from a user-centered perspective. (I’ll describe parts of this approach later, but for now let me get back to the point of this post.)

During this part of my career, I had the good fortune to work with a design genius. This guy seemed to instantly grok the essence of a design problem and, within a few days, could prototype an elegant solution that was functional, beautiful, and usable. Some kind of magic was going on this guy’s head; where most saw only an overwhelming mass of requirements and technical constraints, this guy had an uncanny way of seeing the signal through the noise.

This got me thinking: what is so different about this guy’s mind that allows him to solve design problems so effortlessly? And more importantly, is there a way for virtually anyone to develop a “design mind” like his?

For the past fifteen years or so I have pursued an answer to this question. And after all this time, I can finally report that the answer to this question is…

…more questions.

Actually not just more questions, but better questions. E. E. Cummings was right:

Always the beautiful answer who asks a more beautiful question

The design mind distills a design problem down to the essential few questions that, if asked in the right sequence and answered in a thoughtful way, are almost guaranteed to produce an elegant and genuinely user-centered design. The design mind’s thought process is, above all else, simple and effortless. Simple because it is just a series of questions, requiring no complex theories, concepts, or methodologies to understand. Effortless because if you ask a better question, the answers reveal themselves almost automatically.

Understanding the unique circuitry of the design mind is important to anyone who strives to create user-centered solutions – especially now. User-centered design today is anything but simple and effortless. Since human factors engineering started gaining traction in the 1980s, the practice of user-centered design has strained under the addition of dozens of competing design theories, techniques, and methodologies. The field has mutated into something resembling version 12.0 software: patched and bloated with unnecessary features, all crammed together into a framework that it outgrew years ago. Just take a look at the visual map of the design process on www.usabiliity.gov if you don’t believe me.

This complexity was the motivating force for creating our streamlined Information-Driven Design approach back when I had my dream job. We just didn’t have the time or resources to do UX “right.” And the few times we did get the funding and time to do it “right” – sometimes with the help of the most preeminent design consultancies in the field – our results, as measured by customer feedback, were still lackluster.

In my experience, many so-called UX best practices, and the lovely, impressive, complicated artifacts they produce, are disregarded as soon as they are completed. They simply don’t work in the real world. Many of these activities are dead ends: the output from one activity does not provide input to the next and thus gets filed away and forgotten. Even essential activities like observational research, if not performed with the correct focus, simply overwhelm the project team with useless data, adding noise and time to the design process, making it all that much harder to see the solution. But all the while the team deludes itself into thinking they’re making progress because, after all, they’re incredibly busy filling walls with post-it notes, making pretty PowerPoint slides to impress their stakeholders, and diligently checking off activities in the project plan and removing user stories from the backlog.

We need to shift our focus away from methodologies, workflows, and artifacts, and instead focus our efforts on finding a simpler way of thinking. We need to conduct a metabolic brain scan of the design mind to find out how it works.

In the posts to follow, I’m going to try to discover – not a business process or a development process – but a thought process for designing experiences, specifically the experiences people have when using technology. Like all thought processes, this one will be expressed in the form of a series of questions. My goal is not to invent new processes or methodologies or buzzwords, or to debunk existing processes or methodologies or buzzwords, but to discover which concepts and activities really are essential to answering each design question.

This series of posts is truly an attempt at discovery, meaning that as of this moment, I don’t know where this thought experiment will lead. I may hit a wall and discover that the design mind really is unknowable, a mysterious gift given only to a few. I may conclude that UX design really is as complex as portrayed by usability.gov. Or I may discover that simplifying design into a sequence of questions is a problem that I lack the ability to solve.

But even if I hit the wall, perhaps it will inspire someone else to take up the challenge and complete it.

Simplicity, simplicity, simplicity! I say, let your affairs be as two or three, and not a hundred or a thousand … Simplify, simplify.

Walden, Henry David Thoreau

 

Next: The Design Mind Litmus Test

Three beers. Three realizations. One take away.

My Dinner with Bill

From time to time, Bill*, a friend of mine, and I meet for beers. Like most people, we catch up by trading stories. We are amateur philosophers, though. So we spend time looking for patterns, drawing lessons, and abstracting rules, most of which can be expressed as follows:

                               This new situation, X, resembles old situation, Y. Try using rule B.

Beer three

By about beer number three, Continue reading

Integrating Design Thinking with Agile SD

Agile Experience Design
Agile software developement is antithetical to UX design as I’ve practiced it.  I keep bumping into developer-centric Agile companies where  up front, deliberative UX thinking is instantly rejected as old school waterfall and document heavy.
The case against Agile SD
The questions I–and most experienced designers have–are this: How can you design a complex system by focusing solely on its individual parts? Will a useful and coherent vision magically emerge? How does Agile match up with integrative, system desgin approaches, like Tim Brown’s Design Thinking ?
Agile Experience Design
The book Agile Experience Design by Lindsay Ratcliffe and Marc McNeill addresses these questions. It is chock full of good ideas and practical advice. I’ve included some thoughts from the book below.

Continue reading