When we’re building products for people, designers often do something called “needs finding” which translates roughly into “looking for problems in users’ lives that we can solve.” But there’s a problem with this. It’s a widely held belief that, if a company can find a problem that is bad enough, people will buy a product that solves it.
That’s often true. But sometimes it isn’t. And when it isn’t true, that’s when really well designed, well intentioned products can fail to find a market.
When isn’t it true?
When I tell product managers and entrepreneurs that their dream customers might not buy this product—even if the product solves a problem—sometimes they get angry.
“No!” the managers and entrepreneurs yell. “This is a serious problem for my users! They struggle with this thing every day! They told us this. We saw them struggling with it. We did our research!”
But think about all of the problems that you encounter in a day. Some of them are almost entirely in your control, like deciding how to feed yourself. Some of them are largely out of your control, like sitting in traffic on the way to work. Some of them are almost entirely out of your control, like certain types of health problems.
So, there you are. Sitting in traffic, with a migraine, and trying to figure out what you want for lunch. Which problem do you solve?
Do you solve the worst one? The one that happens every day? The easiest one? Do you give up entirely and just turn around and go back to bed? The only thing that most people won’t do is to solve all of them all at once.
In other words, every day, humans use their limited emotional resources to solve specific problems while they choose to live with other problems or put off solving them until another day.
This tendency of humans to not always solve their worst problems is incredibly important for you to recognize when you’re doing early user research because it has implications for your product. Just because you’ve identified a serious problem doesn’t mean that anybody will pay you to solve it for them.
And remember, when we’re talking about “payment,” we’re not necessarily just talking about money. Free products are often only free if your time has no value. Sure, some products cost money, but people also pay with their time, attention, and effort. If you’re asking somebody to spend hours learning how to use your product, you’ve just charged them a fairly high hourly rate for your free product. You’d better make it worth their while.
You can do something about this
So, how can you separate out the problems that people will pay you to solve from the problems they won’t? Sure, intensity, frequency, and difficulty of solving the problem can influence whether a user will try to solve it. But there’s an even more important thing to look for: Intent to solve.
For example, if you’re a gym owner, and you talk to three women, all of whom say they want to get into better shape, which of the following sounds like the person most likely to join your gym?
a) I’m in terrible shape, and it’s really affecting my health. I’ve never joined a gym, but I’m definitely going to do it this year.
b) I really love running and swimming at my neighborhood pool, and I consider myself to be in pretty good shape. But I’m not a fan of gyms.
c) I’m in ok shape. I’ve belonged to several gyms in the past, but I don’t currently belong to one.
Did you say C? You should have.
Sure, A specifically states that she is going to join a gym and her perceived problem is larger than the other two, but we’ve all declared that we’re absolutely going to do something this year and then not done it. That’s what New Year’s resolutions are. B seems perfectly happy with her routine and doesn’t really have the problem that we’re solving.
C, on the other hand, shows both motivation and a past intent to solve the problem in the way that you, as a gym owner, would like. In other words, she has previously sought ways to get into better shape and has even spent money on gyms. She has shown an intent to solve in the past which is an excellent predictor of her behavior in the future.
There is one notable exception
But hang on. I know what you’re thinking. You’re thinking “but what about Twitter?” Or maybe Snapchat, or WhatsApp, or a dozen other products that solve problems that people didn’t know they had.
It’s true, there are products that don’t solve an obvious problem. Things like Twitter create new behaviors (sort of) and don’t seem to solve anything that anybody ever intended to solve before Twitter came along.
Now, we could argue all day about whether or not Twitter solves a specific problem or perhaps many problems—or even creates problems. The important thing to point out here is that, when you’re creating a product that is truly going to create a new behavior, it is just much, much harder to validate before you build. That’s doubly true if the product relies on network effects, like Twitter does.
Honestly, there may simply be no way to tell if something like Twitter is going to take off before you build anything at all. That’s why, although we do have things like Twitter, we also have tens of thousands of social networking sites and apps that nobody’s ever heard of.
What to look for
If your product does solve a problem that people likely knows exists, though, there’s a very useful technique for figuring out if it’s a good one to solve.
We’ll assume for the moment that you’re already doing user research and customer development. You’re building something, so obviously you’re talking to people who you think might be in the market for such a product—or at least people who have the problem that your product solves.
Just talking to people though, isn’t enough; you have to ask them the right questions. Instead of just asking them questions designed to confirm whether or not they have a specific problem, you need to ask questions designed to find out if they have already shown an “intent to solve” that problem.
What you’re looking for is not just a problem—in the case of the gym owner, a potential user wanting to get into better shape—you’re also looking for a previous behavior of trying to solve the problem. Bonus points if they have spent money trying to solve the problem.
When you find a serious problem that people have tried and failed to solve, you can generally count on their trying to solve it again in the future. Ideally, you want something that they’re actively searching for a solution to right now.
If you want to convince somebody to join your gym, it’s much easier to start with somebody who already wants to join a gym. At that point, you’re being compared to all other gyms. You’re not being compared to literally everything else that the user could do with her money and time.
Humans encounter all sorts of problems every day. Most, we just ignore or deal with. Only a few reach a level that we will spend our precious resources to solve. If you find a problem that is serious enough that people have already shown an intent to solve, it will be far easier to convince people to try your solution.
If you think you have a brilliant idea for a product that creates a brand new form of user behavior and may or may not solve a particular problem, more power to you. It’s not impossible to make it work, but it’s significantly harder to get it adopted than the millions of things that solve real problems that people encounter every day.
For the rest of you who want to make sure a problem really exists before you try to solve it, try evaluating your user’s intent to solve before you build anything. It’ll give you tremendous insight into whether or not your product will be adopted.
Higher education is poised to help produce the next generation of user experience designers, but we can’t do it alone. In the wake of Fred Beecher’s recent “Ending the UX Designer Drought” and studies by Onward Search, UserTesting, and the Nielsen Norman Group, it is clear that the UX market is booming and that UX designers enjoy a high level of job satisfaction. It is also clear that too few UX professionals exist to meet current demand.
And while apprenticeship programs like Fred’s can help meet much of this demand, those of us in higher ed who have hitched our research, teaching, and service agendas–our entire professional identities–to UX are uniquely positioned to help students navigate to those apprenticeship programs, or even to help take the brunt of some of this training.
If we are to do so, however, we need members of industry to partner with us.
Obstacles to establishing UX workflows in higher ed
Before discussing ways that higher ed can help produce UX designers, let me discuss obstacles that we academics face, obstacles that make it difficult to nimbly respond to industry realities. I’m sure it won’t be news to anyone, for example, that the academy is very siloed.
At the same time that knowledge in the academy is often chopped up into discrete units called disciplines, however, there are other obstacles to establishing UX as a real concern that are specific to state- and federal-funded institutions of higher learning. The first of these that must not be underestimated is a status quo mentality that is endemic to academia but that doesn’t come from academics.
That may sound confusing, but remember that our schools are tied to state and federal budgets that are ultimately decided by politicians, not educators. Every program, major, minor, course, or even revision to an existing course, has to be vetted by administrators under increasing pressure by legislators to make every dollar count. This is often called a “strategic plan” in higher ed, and is our version of a business process model.
In this context, administrative response historically has been to veto any new programs that don’t clearly extend from an existing and well-established discipline. This may sound like a death knell for UX, an interdisciplinary practice that by its nature draws on knowledge from a wide variety of contexts, some academic and some not. And though it is a significant challenge, it is not an insurmountable one. It simply means that being a UX professional in higher ed means working within, and sometimes against, disciplinary boundaries.
What I mean by “disciplinary boundaries” is that every academic must do work that is understandable as a form of research, teaching, and/or service to a particular academic discipline and to a particular academic institution. Let me give a personal example to demonstrate what this workflow looks like. From my own discipline of technical communication and my own program seated at East Carolina University, I’m responsible for doing research, teaching, and service work that is recognizable as a contribution to the field of technical communication as well as to mid-size, doctoral-granting, state university.
This means that whatever I research has to be intelligible to other members of my field or I won’t get published and I won’t get tenure. This also means that I’m responsible for teaching a dizzying array of skill sets from technical writing to web design to UX design. Service is notoriously ill-defined in higher ed but typically requires serving on committees, serving on boards of professional organizations, and some form of community service (e.g. service-learning or volunteering).
I also should mention that there are exceptions to this workflow. Academic programs capable of reliably training students in the discipline of UX all on their own have relatively recently sprung up at places like Kent State, Michigan State, and University of Washington. Largely interdisciplinary, these programs require a kind of perfect storm to form, such as a massive restructuring of a university system, a cluster of faculty hires in a particular specialization, or some very adventurous college administrators.
For the most part, what I’ve described is the uber-structure many academic professionals must work within. But there are ways to inject UX practices into this structure. Say I’m asked to teach a technical writing class, for instance, which is a central course in our program. A big focus of this class is the creation of documentation, because that’s part of the course description that was approved. But how is “documentation” increasingly being produced? In agile environments, where UXers or tech writers often build it directly into the information architecture of the product they’re designing. Following this trend, my recent technical writing course featured a series of learning modules that focused as much on traditional modes of documentation as it did on content strategy and IA.
For UX partnerships to work in higher ed, they must be enacted as a form of research, teaching, and/or service.
Why is this important? Because if many academic professionals must engage in work that fits this basic workflow, it means that we must always produce scholarship, teach courses, and engage in service that furthers the missions of our institutions as well as the knowledge-making practices of our disciplines. For UX partnerships to work in higher ed, they must be enacted as a form of research, teaching, and/or service.
Why academic-industry partnerships MUST exist
At the same time, it is also arguable that industry organizations cannot meet the need for new UX professionals alone, and more importantly, they shouldn’t have to. Currently, there are over 20 million students enrolled in institutions of higher education. And though of course only a fraction of those students might have the inclination to become a UX designer, that is simply too big a pool of potential new designers to pass up.
Academics can’t train UX professionals by ourselves, either. The discipline moves too fast and we are tied to a workflow that is very different from that of industry. This is thus a partnership that must happen to sustainably produce sufficient UX professionals to meet current demand. Millions of people from all walks of life pass through our classrooms, and if we can reach even a tiny percentage of those people and can set them on a path towards a career in UX, then UX professionals in both the academy and industry have an obligation to do so.
So, how can academic-industry partnerships be built that allow academics to keep their jobs? That’s what I turn to next.
Academic research can be produced in many forms: empirical, theoretical, practice-based, quantitative, qualitative, and the like. All we really need from industry is access. We need to be able to see inside your organizations, to pick your brains through research interviews, and to survey you about new trends. We need to do focus groups about theories we have held for years to see if they pass muster with industry realities.
The best thing you can do for us in this context, in other words, is collaborate with us on our research projects.
The largest venue within which UX could take off in higher ed is through teaching. In my own tenure as a college-level instructor for over ten years now I have taught 4-8 courses per year of 20-30 students per course. That means that conservatively I have personally taught over 1,500 students ranging from college freshman all the way up to graduate students, and in topics ranging from basic writing to UX design.
The only reason I know what UX is, and how to give students some practice in it, however, is because I have reached out to folks in industry and they have responded. I have gone to conferences like the IA Summit. I have completed dozens of webinars and workshops. I am an active member of my local chapter of the UXPA. And I have collaborated with industry partners on projects ranging from individual articles on how to teach UX to entire courses in UX.
We know how to teach, but we will never be as cutting-edge at UX as those of you who work as UX designers every single day.
The best thing you can do for those of us who have opportunities to teach UX, then, is to help us with the subject matter we teach in our courses. We’re educators. We know how to teach, but we will never be as cutting-edge at UX as those of you who work as UX designers every single day. We need help with what to teach.
There are also endless opportunities to get involved in academic service that fuels the UX discipline. This can range from the creation of book clubs and informal meet-ups to service-learning partnerships and other forms of contextualized learning. In any given community, there are thousands of local non-profits and schools in need of UX help, from content strategy to CMS development to usability testing existing websites. Hardly any of these organizations can afford to hire a UX professional, but students could work in partnership with a UX professional to serve them, and could develop expertise as a result.
On any given college campus, there are also dozens of student organizations on everything from business management to community service to web design, many of whom look for guest speakers to talk to them about career opportunities, how to land a job, how to gain traction in a new field, etc. It simply cannot be overstated that there is simply no shortage of mentoring opportunities for industry professionals to entertain.
Mentoring is thus the simplest and yet most valuable form of service. And it is incredibly simple: think about the first opportunity you got in UX and try to steer someone else toward that kind of opportunity, or even create one for them in your own organization.
This is what these partnerships could look like
We academics are the people who write those textbooks you were forced to buy in every introductory class in college. Imagine if they were relevant. Imagine if you helped us write them. Or imagine if you helped us write how-to articles for our academic journals so that other academic professionals could learn about UX in a venue that is intelligible to them. Or imagine if you helped perform research projects that were actually sound instances of UX design so that we could begin to solve our own UX problems and maybe even contribute some new solutions for you as well.
Imagine if you volunteered to come speak at our conferences about any of these topics, or even at informal meet-ups and colloquia at our institutions. We can rarely afford to pay you what you’re worth, or what you get for industry-sponsored conferences, but we will always appreciate the knowledge you bring.
Those of us in higher ed are in a position to introduce UX on a scale upon which it has never before been introduced.
Think of it this way: how many eighteen-year-olds graduate from high school and when asked by their guidance counselor what they want to be, say: “I want to be a UX designer!” Few, if any. Many of those bright young people enroll in college courses, however, part-time or full-time. Perhaps they decide to major in computer science, where they first learn about usability and its role in application development. Or perhaps they take a class in technical communication where they first encounter the central concepts of information architecture. Those of us in higher ed are in a position to introduce UX on a scale upon which it has never before been introduced.
But we need your help. If you don’t think we’re preparing students for opportunities as UX designers fresh out of our programs, then tell us that. Better yet: agree to be a guest speaker in our classes. Better yet: help us create learning modules on UX that we can use in multiple classes. Better yet: help us create and advocate for an entire class in UX. Better yet: volunteer to co-teach the class with us. Better yet: help us form an industry advisory committee for our entire program. The list goes on and on.
If you want that 18-year-old who is fresh out of high school to consider going into a field they may have never heard of, a field that probably first makes sense to them as a subset of an existing major, partner with your local university or community college to make sure that 18-year-old does hear about UX, to make sure they get some training in it, and to make sure they’re on a path toward being useful to you someday.
This is how all of this makes for a stronger UX community
If nothing else, I hope to start a conversation around expanding UX partnerships between interested professionals within both higher ed and industry. These partnerships exist, but they need to be the norm, not the exception. If every industry professional who reads this article volunteers as a research partner, teacher consultant, mentor, or service-learning partner at their local university, UX could become one of the most sought-after careers in higher ed. Students could be beating down academic doors asking for more experience in UX.
That kind of demand could create the kind of pressure we academics need to start new courses and majors in UX. If our students are demanding UX, then we can give it to them. If our students have no idea what UX is because they don’t hear about it until their senior year, then it becomes very difficult to create high-quality UX learning opportunities.
In the past three years, since my real interest in UX began, I have been working diligently to introduce students to UX in every course I teach. That’s a tall order considering that I can’t simply teach five sections (my current teaching load) of “Introductory UX Design” every year. I have had the opportunity to teach some standalone UX courses, but, as I mentioned above, mostly I introduce UX through individual learning modules and homework assignments in classes in technical communication, business writing, and web design.
But I have also met resistance, and not only from the academic side. A lot of industry-based people have helped me and inspired me in immeasurable ways, but I have also been met with downright suspicion. I have been asked if I feel like I am a form of competition for industry-based apprenticeship programs and for the newly formed Unicorn Institute, the UX field’s first standalone design school. Mostly, I have been asked repeatedly how I know enough about UX to teach it.
And the simple fact of the matter is: I don’t. I have been researching and practicing UX for three years now, research that has included in-depth practice with nearly every UX method on the market. I have published both research and practice-based articles on it (some of which were co-authored by UX designers), and have taught numerous courses in it, but I am not a full-time UX designer. Professionals like me are also all that stand between industry organizations looking to hire new UX talent and those 20 million people I mentioned earlier, few of whom start college even knowing what UX is.
My invitation is to see us as partners in helping to improve the quality of UX education regardless of where students and mentees are getting that education.
So, rather than seeing professionals like me as a form of competition–we simply don’t have the resources to compete with industry-based organizations, even if we wanted to–my invitation is to see us as partners in helping to improve the quality of UX education regardless of where students and mentees are getting that education.
Let’s face it: UX is difficult for many of us who study it, teach it, and do it for a living to define. We owe it to the next generation of UX professionals to introduce them to UX as soon as possible in their professional development, to be the frontline of UX education, so-to-speak. That’s the only way to make certain that students who are dedicated to becoming UX professionals have the opportunities they need to make that possibility a reality.
Why are you in UX? It probably isn’t to get rich. Yes, there is plenty of money in being a UX professional today. If you’re competent, you should be enjoying a very nice lifestyle. But we do this not for money–being on the business side would be far better at achieving that goal. We do it for creative reasons, expressive reasons, quality of life reasons, perhaps even altruistic reasons.
Yet, despite the broader motivations we share for choosing our vocation, we are rarely the community that spawns big ideas. It is more likely to be the capitalist, the marketer, or even the philosopher. But, why? I’ve lived in these communities, too–a dot-com CEO for a few years, an advertising executive for a few years, working in university to a philosophy Ph.D.–and I can tell you the paragons of those communities are no smarter than the paragons of our own. Yes, they may have more ambition and audacity and expectation of being big, but they are no better suited to develop big ideas or make radical change in the world than we are. I say this as someone who has been in all of these worlds and continues to choose to associate with the UX community as opposed to the others.
As a group, we are creative. We are open-minded. We try to create solutions that solve problems in the best possible way, and we do so for people. Practical solutions. Ideas based in real-world application and context. As the U.S. Congress has a historically low approval rate, as Antarctica melts into the oceans, as ISIS beheads innocents, and Russia maneuvers to swallow up the Ukraine, we need better solutions.
Why not us? I would argue we are uniquely able to provide the critical solutions to move humanity forward, solutions that synthesize technology with a concern for and understanding of the human condition.
However, user experience is typically focused on the “things” within the world. Yes, sure, with a focus on how people interrelate with those things but even when we are looking at “ecosystems” of experiences, they generally relate to ideas, structures, and systems that other people have imagined. We may deliver the existing idea in a better way, but it is not something that spawned from our mind.
Like many people in the United States, I have become increasingly disenchanted with our political system. As our population grows our legislature does not keep pace, meaning that each of us are farther and farther removed from the decisions being made for us in the Federal government. Ours is supposed to be a government of self-representation, but our dwindling connection to those decision makers only reinforces a plutocracy–a government for the wealthy–where she who has the most money, wins. The Congressional approval rate is now under 10%, a stunning indictment on the current system. This is happening against a backdrop where personal computing technologies are removing the old barriers that required an abstracted form of representational government in the first place. The situation is simply begging for a change.
It is audacious in its charter and sure to be squashed by people who have significant monetary incentive to keep the current, crooked, hopelessly out-of-date model in place. But frankly, my friends, I don’t give a damn. I want to make the world better. I will make the world better, and these ideas will be some part of that in ways small or larger. You can develop solutions that make the world better, too. You just need to think bigger, take on some of those challenges, and have the courage to throw it out there into and against systems that will surely resist it.
Let’s stop tolerating the things that suck. We are explorers, creators, change makers. We don’t need Ph.D.s or splashy titles or high profit companies to make the world better; we just need to build the damn things.
I published Redesign Democracy in an honest effort to propose a better path that could actually be implemented and make the world much better. But there is a second reason:
I want to inspire you to create even better things. To dare. To dream. To put it all out there, whatever.
The worst thing you do is get a few people to think differently. The best? If your idea is good, and your timing is right, and you get a little lucky, you just might change the whole, entire, wonderful world that we share with over seven billion others.
What about the world would you like to see changed, and how might we be a catalyst to change it? Please share your ideas in the comments, below.
I went to art school. I studied painting until I fell out with the abstract expressionists and switched to photography. But I can draw.
What I cannot do is diagram. I always wanted to. I have models in my head all the time of how things work. But when it comes time to make a visual model of those ideas, I can’t figure out to to represent them. I find myself resorting to pre-existing models like four-squares or the Sierpinski triangle (I dig fractals.) For example:
Other than the oh-god-my-eyes color choices, my social architecture diagram has deeper problems. For example, the ideas in it are limited to threes within threes because that’s the form triangles take. The model served to communicate my ideas well enough for the sake of my workshop, but… shouldn’t form FOLLOW meaning? If I had more than four elements for any section, I’d have to either collapse two, or fudge it in some other way. I was sacrificing accuracy for consistency. But I didn’t know how to make to make it better.
A concept model is a visual representation of a set of ideas that clarifies the concept for both the thinker and the audience. It is a useful and powerful tool for user experience designers but also for business, engineering, and marketing… basically anyone who needs to communicate complexity. Which is most of us, these days.
The best known concept model in the user experience profession is probably Jesse James Garrett’s “Elements of User Experience.” The best known in start-up circles is the lean startup process. Both of these models encapsulate the ideas they hold in such a memorable way that they launched movements.
If you wish to clearly present a set of ideas to an audience and represent how they fit together, a diagram is much more powerful than words alone. Dan Roam points this out in his latest book, Blah Blah Blah:
“The more we draw, the more our ideas become visible, and as they become visible they become clear, and as they become clear they become easier to discuss—which in the virtuous cycle of visual thinking prompts us to discuss even more.”
Concept models can serve many purposes. You can use concept models to show your teammates how a complex website is organized before the site is built…
… or to help teammates understand how the site currently works…
… or to show end users how a service works, to help sell it.
I teach user experience design, and my syllabus always includes concept models. Students of mine who do a concept model before working on the interaction design and information architecture always make better and more coherent products. The act of ordering information forces them to think through how all the disparate elements of a product fit together.
The workshop was brain-candy and eye-opening: They covered how the brain processes information and how ways of interacting with information can promote understanding. BUT I still couldn’t make a model to save my life. I didn’t know where to begin!
At lunch, Stephen was manning the room while Karl grabbed food for them. I had been struggling with a model for negotiation I wanted for a talk I was presenting later in the program. Seeing Stephen idle, I pounced and begged for help.
Stephan P. Anderson is author of Seductive Interfaces and the upcoming Design for Understanding. He’s also a patient soul who will put up with ham-handed diagramming and ridiculous requests. He started to sketch my model and tell me what he was thinking as he drew. Then I had my bingo moment: Stephen had forgotten what it was like not to know how to begin! This happens to all experts. After a while some knowledge is so deeply embedded in their psyche they forgot what it was like not to know. They then teach the nuances rather than the fundamentals.
I suggested we do a think aloud protocol while he made a concept diagram; he would draw, and I’d prompt him to talk about what was going through his mind. He was excited to have me reflect his thinking back to him so he could become a better teacher as well. We arranged to have a sketching session after the workshop.
Later in the day, we met in the quiet hotel bar with wine and a sketchbook. I asked him what he wanted to draw. “Do you have something you are working on?” he asked. “That way I can focus on the model, rather than rethinking the ideas.”
Did I have a model I was struggling with? Always! I shared my new theory of the nature of digital products. I’ll be writing that up in another article when it’s done, but for now, the short version is that one must iterate through the elements of digital design, which include the framework, interactions, information structure, and aesthetics. But a product doesn’t become an experience until a person interacts with it; your design cannot be known until you see what happens when a human shows up.
Stephen’s first step was to ask me about my goal for the model. I said it was for students and young practitioners to understand the interdependencies of the elements, so they have a more iterative approach. And for critics to be able to understand why things are different, both good and bad.
Next, he did what I’d call a idea inventory. He brainstormed more elements that might play into the model. He made sure no ideas were left out. He made notes of those he suspected might be important in the margins. He sketched as he thought, sometimes just making meaningless marks, as if warming up his hands.
He then carefully asked about each element in my theory, making sure he understood each. What was an information structure and what was a framework and were they different? I ended up telling a little story about a product to make sure he got what I was explaining. I began to draw too, encouraged by his easy scribbles.
Finally, Stephen noted the relationships of the items to each other. Were some things subsets of others? Were some overlapping, or resulting?
Once he knew what each item was, and how they were related to each other, he began to sketch in earnest. He said, “I always start with circles because edges mean something. They mean you have four items, or five. Circles leave room for play.” His circles quickly became blobs and then shapes.
I don’t know if he’d normally talk to himself out loud when not encouraged to do so, but it was fascinating to to hear him free associate concepts, then draw them out. A string of concepts became a string of beads; moving through an experience became moving through a tunnel; intertwined ideas were a braid. Any important idea got a drawing.
Each time he completed a mini-model, he’d evaluate what was missing and what was working and take that insight to the next drawing. He made dozens of these little thumbnail drawings.
Stephen said, “one shape leads to another…a single word sparks a new representation—we’re always ‘pivoting’ from one thumbnail to the next…”
He pointed out what concepts were left out, or where they could be misinterpreted.
“You want to avoid 3-d, because it’s fraught with problems. You want to be able to sketch it on a napkin.” —Stephen Anderson, on keeping in mind the model’s goal
At one point, he became tapped out, and we spoke of other things. We stared out the window at the harbor, and I drank some of my wine, forgotten in the excitement of drawing and talking.
Then suddenly he started in again and produced a flurry of new drawings. I realized resting and mulling was important too. I was a bit annoyed with myself. An article doesn’t come out perfect in one writing session. Why should I expect a concept model to just materialize?
Finally he came to a stop, several pages filled with a jumble of images. We didn’t have a model, but we had many good directions. As we finished our drinks and headed toward the opening reception, Stephen told me, “You gotta get Dan Brown to do this, too.”
Dan M. Brown is best known in the user experience design community as author of Communicating Design and Designing Together. Both books benefit greatly by clear and succinct conceptual models, and the former even talks about how to use them in the design process:
Purpose—What are concept models for?
There really is only one reason to create a concept model: to understand the different kinds of information that the site needs to display. This structure can drive requirements for the page designs, helping you to determine how to link templates to each other. With the structure ironed out, you might also use the model to help scope your project—determining what parts of the site to build when.
Audience—Who uses them?
Use concept models for yourself. Ultimately, they are the most selfish, introspective, and self-indulgent artifact, a means for facilitating your own creative process.”
–Communicating Design: Developing Web Site Documentation for Design and Planning 2nd Edition, Dan Brown, 2010
Clearly, a guy I should be talking to!
The IA Summit was held in sunny San Diego in a hotel with not one but two swimming pools, so Dan had brought his family with him. When I asked him if I could watch him draw a concept model, he said, “I’m at the coffee shop with the boys around 6:30 every morning.”
You take what you can get.
The next morning Dan settled the boys in a corner with books, pastries, and an emergency iPad, and we got to work. We agreed he’d model the same concept, to control for variations. By now I had created a formula for the idea: (F+In+Is+Ae)+P=E. Framework, interactions, information structure, and aesthetics plus a person makes an experience. I was modeling in words as my friends were modeling in pictures.
I took Dan through the same story of an iterative product design process, since it had helped Stephen. I sketched it out. I felt like my hands were waking up from a long sleep, and they were eager to hold a pen now.
As I spoke, Dan wrote down key ideas and also began to scribble. He used the same process as Stephen: collecting the concepts then inspecting them for hidden complexity.
“A question I ask myself is ‘what needs unpacking?’ I can’t diagram an idea until it’s clear in my own brain.” —Dan Brown
He then took each concept and free associated all the sub-elements of the concept. He drew them out loosely, mind-map style.
Dan also started with the goal and wrote it out across the page.
He also asked explicitly who the model was for. To draw, he needed to visualize the audience. This reminded me of a recent presentation workshop at Duarte where we literally drew pictures of our audience. No work can be good unless you know who it’s for.
Dan made sure he didn’t carry anything in his head: All ideas were put on paper as a note or a sketch. When he had to turn a page, he ripped it out to lay it next to the other pages. I realized how critical it was to have plenty of room to see everything at once. I saw the same technique of storytelling and drawing of ideas.
Around now, Stephen joined us. He was excited to see what Dan came up with, enough to also climb out of bed at the crack of dawn. I listened as the two diagrammers discussed the poster session and the strengths and weaknesses of the ideas that had been presented.
Dan said, “You can look at people’s posters and see their process. They are so close to their own narrative…In one poster, the key framework was rendered in a very pale text. It was a good story, but there are things you want to jump off the page. For her, my guess is those steps were so self-evident she didn’t see need to highlight them.”
You have to have a beginner’s mind to explain to beginners.
“Speaking of beginner’s mind, so much of my design process is to throw it all out start all over again.” —Dan Brown
Now Dan began to model the concept. He emphasized the importance of sticking with very simple geometry–circles, squares, triangles, lines–not fussing with trying to find a perfect model at the beginning, just exploring the ideas and their relationships.
He also mentioned he begins with any concept in the model and doesn’t worry about representing order at first. He starts with what catches his interest to get familiar with the ideas.
Dan then deviated from Stephen by seeking the focal point. What concept held all the others together? What was the most important or key idea? He tried out placing one idea, then the other, in the center to see if felt right.
After scrapping one bowtie model, he paused. “I sometimes retreat into common structures and see how these common structures might speak to me. For example, time is one of those fundamental aspects, so I ask myself: How much do I need to show time here?”
He demonstrated by drawing swimlanes and sketched the ideas and their relationships in time.
“Are there other elements you often look for, like time?” I asked
“People,” he replied. “People and time are familiar concepts, easy for an audience to relate to. By using them as a foundation for a model, I’ve already made it easier for people to ‘get on board.'”
He stared at the paper, deep in thought.
Stephen then pointed at the page. “What Dan did here,” he said, poking at where Dan wrote out goal and audience, “I did also but didn’t externalize. I was holding it in my memory, but I like having it on the paper better.”
Eventually Dan, too, was tapped out, and his sons began to play Let It Go on the iPad at higher and higher volumes. He separated his sons from the electronics and left to prepare for the swimming pool.
After Dan, I knew I wanted to try to get one more person to model. Since I was lucky enough to be at a conference full of diagrammers, I chased Joe Elmendorf of The Understanding Group. He had just given a talk on Modeling for Clarity that my friends were raving about. And, with my luck still holding, I got to have breakfast with him. Happily, at 8 am this time.
Again, I saw what were becoming familiar concepts (inventory, inspection, relationships, then talk-draw.) I then focused on how he differed from Stephen and Dan. He choose to use the title of the diagram as an element. He did not iterate as widely as Stephen. He was the first person to argue with me about the validity of my theory, which was a great way to understand it (and benefited me by making it better!).
As well, he reinforced something Stephen had mentioned in his workshop and that Dan was obviously doing: Joe had a large mental library of typical models to draw upon, which got him started. Stephen keeps a Pinterest board full of inspiration, if you want to start your own “lego box” of models.
Overall, there were so many familiar patterns I saw in his approach, the differences were more interesting than important. I had my answer. I knew how they did it.
On the last day of the conference in the afternoon, Stephen and I were scribbling further on the model, playing with petals for the elements, when Dan Willis joined us. Dan is also a master of models as well as an inveterate sketcher.
Although Dan declined to diagram for me, claiming brain fatigue (a reasonable claim at this year’s Summit) he pulled up a chair and sat sketching next to us. It was companionable, to sit and talk and draw ideas. We moved back and forth from discussing life to discussing the ideas, teasing, joking, drawing. As we chatted, I realized this was a part of the secret. You need a thinking partner. Sometimes it’s paper, sometimes it’s friends; but it’s best when it’s both. It doesn’t always matter what you draw, just that you draw.
Dan Willis drawing nearby makes me happy.
Our brains work better when our hands are busy.
Later, sitting in the back of a session, I lobbed a model at Stephen, and he shot back with his own.
Then I saw another step, one which Dan had alluded to when he mentioned the poster with the key point too pale to read: You have to refine the model to communicate effectively. Type, color, and labels are all a key part of the communication process. While the model did stand alone without the color and type, adding those–and most especially getting labels right–made the model more effective.
After getting home, I started sketching how concept models were made. I drafted this article and then asked my friend Dave Gray if he’d do a quick edit. Dave was the founder of Xplane, a company that used diagrams–concept and other–to transform companies. Dave has been a proponent of visual thinking and clear modeling for years, and I consider him the master of making ideas visible.
Life then intervened and this article sat. I was busy with several things, including Lou Rosenfeld’s 32 Awesome Practical UX Tips. Dave presented right before me, and watching him sketch, I realized I just had to get one more diagramming session in. It was not enough to have him comment, I needed to see him draw. I was grateful I did; otherwise, I would have missed a crucial piece of the puzzle.
We hopped on a Google Hangout and he also drew out that same darn design model for me. I saw familiar patterns in his approach: inventory, unpack, relationship exploration. But he added a critical step I hadn’t thought of before: Test the model.
He’s currently writing a book on Agile, and it shows. He said, first design the test, then design the thing. For the model, he suggested using his WhoDo Gamestorming tool as a way to design a test of the effectiveness of the model. He lists who the model is for and what they will do if they understand the model.
Designing a test of the model’s success radically clarified the goals for the model. Testing it would make sure it did what you wanted it to do.
So then I sat down to make a model of how to make models. And it came easily.
Determine the goal: How will the model be used, by whom? What is the job of the model? To change minds, explain a concept, simplify complexity?
Inventory the concepts: Brainstorm many parts of your concept. Keep adding more in the margins as you go.
Inspect the concepts: Are there many concepts hiding in one? Do you really understand each idea?
Determine the relationships: How do the concepts interact?
Decision point: Do I understand the ideas and what I’m trying to communicate? Test: Ask yourself if the model “feels” right. If yes, then continue.
Iterate with words and pictures: Talk to yourself and draw it out!
Evaluate with yourself/the client: Keep making sure the drawings match the ideas you wish to communicate. Don’t punk out early! Rest if you need to!
Decision point: Does my audience understand the ideas and what I’m trying to communicate? Test: Can my audience answer key questions with the model? If yes, then continue.
Refine: Use color, type, line weight, and labels to make sure you are communicating clearly.
The concept model is invaluable. But like so many useful things, it takes time to make.
When my daughter first started drawing My Little Pony, she expected to start at the ears and draw it perfectly down to the hooves. She was angry when it didn’t work that way, and it took some convincing to get her to block out key shapes then refine the whole, and to use pencil before ink. When I sat down to make a concept model, I made the same mistake! I’d start in Powerpoint or Grafio, and expect perfection to flow from my mind.
No more! Stephen, Dan, Joe, and Dave taught me to play, explore, refine, test, and play some more until the result was right. Thank you all!
As designers, we grapple every day with challenging projects. This of course is part of what keeps us coming back. Some challenges, although not directly related to project work, can still be looked at through a UX lens. In this case, I’m talking about a phenomenon you’re likely familiar with: company reorganization.
If you’ve been through a reorg (that’s ‘reorganization’ in water cooler parlance), you’ve probably experienced your share of the whispers, closed-door meetings, and mixed messages that seem to be par for the course when an organization goes through major changes in size, scope, staffing, or management.
I’ve been through a number of these shuffled decks myself, across several companies, and for a variety of reasons. It’s fair to claim that each one is different, but there’s enough overlap to identify patterns and form some baseline recommendations.
If you’re in a role with decision-making authority, then you’re ideally positioned to ensure that the reorg will be designed as an intentional experience with its actual user base in mind.
However, if you’re like the majority of us who aren’t in a position to make decisions about the reorg, you’re probably still reasonably close to the folks who are. Why not take the initiative and lay out some scenarios and recommendations for how the reorg can be designed for optimal reception and impact on your organization?
Whether it’s planned or not, the scope of the reorg will have an audience far larger than the group of people seemingly affected on paper. The experience of these groups throughout the reorg should be purposefully designed by whomever is running the change management show.
Let’s take a look at who your users are.
The folks who are officially part of the reorg. Their status is changing in some way, be it their actual role, reporting structure, or the like.
Coworkers/teams who have direct or dotted-line dependencies with anyone or any team directly involved in the change.
Coworkers/teams whose only connection is physical or cultural proximity or who ultimately report to the same upper management.
Third party vendors who communicate with or provide services to reorg-affected parties.
Here’s what you need to realize: These groups will be getting bits and pieces of news about the reorg whether or not you craft that message explicitly.
With that in mind, you should ensure the messaging supports the business strategy, is accurate, and speaks to each party’s specific concerns.
This is the difference between an unplanned, unpredictable experience and an intentional, designed experience. It’s a golden opportunity to show your stakeholders they are a valued part of the organization, and you’ve got your arms firmly around managing the changes. If the right preparation goes into the reorg, you can nip in the bud any misinformation and unnecessary stress, building confidence in your team’s leadership and capability as a whole.
The alternative is to risk spending what trust currency you’ve accrued to date.
Now that you know who you’re talking to, what do you say? It’s idealistic to think that you’ll know all the details when you begin planning the reorganization–but you do need to initiate your communications plan as close to the start of planning as you can.
Start by crafting general messaging that indicates the why–the logic being the necessity and desired benefits of the reorg. This should be high level until more details are known. If you know enough about the how to paint a low-res picture, do it.
A little bit of information that’s transparent and honest will go a long way–but take care not to make promises you can’t keep. Things can and will change, so own up to the reality that dates and other details are very much in flux to help you avoid having to take back your words when deadlines shift down the road.
As you approach major milestones in the reorg process and as the details solidify, provide appropriate communications to your audience groups–and do so again once the changes have been rolled out. This may seem like a lot of effort, but rest assured your people are asking questions. It’s up to you to address them proactively.
If a milestone date changes–and it will–the audience who’s been paying attention will still be looking to that date unless you update your wayfinding (in the form of project timeline communications). Without this careful attention to detail, you’re sharing bad information–perhaps more damaging than no information at all.
When the rubber meets the road
Inevitably, one question that will come up repeatedly throughout a reorg is “When does all this actually happen?” In other words, when do we start following the new processes, change how we route requests, start doing this and stop doing that?
For both logistical and psychological reasons, knowing how and when transitions will take place is vital. Often the difference between a stakeholder being stressed out (perhaps becoming a vocal opponent of the changes) versus being calm and confident is the company’s honest commitment to consciously bridging the transition with trained, capable support.
This could be as simple as a window of time during which existing persons or processes can continue to be called upon for support or as complex as an official schedule that shows specifically how and when both the responsibilities AND expectations of the audience segments will change.
It’s not like you can do A:B testing with a reorg. You can, however, do some polling when the initial reorg information is shared, then midstream, and again after the reorg is complete.
Why do this research? As with any project, from your first person perspective, reorg elements might seem obvious–or you may have overlooked some pretty big pieces. Talking with your ‘users’ can be illuminating and also sends the message that their input is desired and valued.
While some reorgs are expressly designed to reduce overhead/staff, reorgs are not always about cutting heads. Often-times it’s a shuffle of resources (people), and if the right discussions happen you can guide that process to a win win.
Using a handy list written by a gentleman you may know of, here are some dimensions coopted for our use. Employ these as you see fit to generate interview material and discover how well your company reorg experience has been crafted.
Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
We can ask our participants what they took away from the reorg communications they were sent. This includes actual group or 1:1 meetings, formal documents, emails, etc.
Find out if the materials conveyed the message so the transition was easy to understand. Did they grasp both the high-level view and the granular details? (In other words, overall strategy and the specific impact to them.)
Efficiency: Once users have learned the design, how quickly can they perform tasks?
If the folks you’re polling have been assigned specific assignments in the reorg, ask early on if they fully understand their instructions and if they could have added any insight that might have decreased task costs or durations. Midstream or late in the game you can follow up to see if those instructions turned out to be clear and accurate enough for the tasks to have been carried out efficiently.
Did task instructions have the most time-saving sequence? Were there steps left out of the tasking communications that had to be discovered and completed?
Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
Remember the telephone game? Someone makes up a story and then each player passes the story on to the next by whispering. When the story makes it back to the author, the details have changed–it’s a different story.
When those involved in a reorg talk with others, they’ll pass along what they know. The simpler the story and the more they’ve understood it, the less you’ll lose in translation.
Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
A successful reorg requires a lot of work and collaboration between groups. Mistakes tend to be costly and have a ripple effect, becoming harder to correct as time goes on. The critical path of these big projects is placed at risk due to missteps due in large part to (wait for it) learnability and memorability, or due to errors introduced by people who have been put off by the lack of efficiency of the reorg process and attempt to forge their own path.
Another source of error is in failing to communicate enough timely information about role changes to employees and contractors. Major change breeds anxiety, and in a job market where workers have the power and employers are constantly on the prowl for good (and hard to find) talent, it’s a mistake to risk wholesale attrition.
Avoid this error by honestly and accurately communicating dates and the likelihood of roles continuing as is or with changes. If roles are going away, be transparent about that too. Better to maintain trust and respect with clear messaging about terminations than to leave folks in doubt and unable to plan for their future.
Satisfaction: How pleasant is it to use the design?
If the reorg does NOT leave a bad taste in everyone’s mouth, and if the stated project goals have been met, you’re doing it right. Reorgs happen for a reason, typically because something’s suboptimal or simply broken. Ultimately, everyone should pull together and work towards a positive outcome resulting in better workflow, lowered cost of doing business, increased job satisfaction, and, of course, $$$.
Regardless of your role in the company and the reorg, consider whether or not you can use your UX superpowers to make the entire process less painful, easier to understand, and more likely to succeed.