4. “Focus as though you
are looking through the
image into the
distance…
very slowly move the
image away from your
face...the hidden image
will magically
appear…good luck!”
8. - Sees the whole picture
- Changes perspectives to see new leverage points in complex systems
- Looks for interdependencies
- Considers how mental models create our futures
- Pays attention to and gives voice to the long-term
- “Goes wide” (uses peripheral vision) to see complex cause and effect
relationships
- Finds where unanticipated consequences emerge
- Focuses on structure, not on blame
- Holds the tension of paradox and controversy without trying to resolve it
quickly
- Makes systems visible through maps and models
- Watches for win/lose mindsets, knowing they usually make matters worse
in situations of high interdependence
- Sees oneself as part of, not outside of, the system
The System Thinking Playbook
34. RESOURCES
The Systems Thinking Playbook, Sweeney/Meadows
Role-playing the Interaction, Stephen Anderson
Just Enough Research, Erika Hall
Co-designing resources, Service Design Tools
The Secret Phrase Top Innovators Use, HBR
Design Sprint Resources, Google Ventures
Editor's Notes
Hi everyone!
My name is Phyllis Treige. I’m really excited to be here today and I’m looking forward to sharing some ideas on how a systems thinking perspective can help with user experience.
Much of my work has been in the public sector, first at the California Court System in San Francisco and now here at the University of Wisconsin-Madison for the past five years. But I’ve also worked at law firms and at a design agency.
So this probably dates me a bit but, does anyone remember these Magic Eye puzzles?
I remember staring at them, like really sweating it out, and feeling kinda cross-eyed and frustrated. And there would always be that one person who could see the hidden image immediately. Anyone?
[Yes, you! You were the jerk that had the rest of us feeling like idiots!]
What do you see?
Since I struggled to see the hidden images, I went looking for some instructions. And that took me to the Magic Eye website.
If you’ve never seen the Magic Eye website -- and why would you unless you’re a nostalgist like me? -- bear with me as we check it out. It’s like a time warp for web design…I can’t resist sharing it.
It turns out that there are some tips for seeing the Magic Eye images.
The funny thing is that I actually remembered these instructions, especially the “good luck!” at the end which could be interpreted as a supportive thing or, from my perspective, like some sort of sadistic challenge.
I think these instructions are interesting because the same guidance could be useful for understanding complexity. It’s about getting perspective, going slowly, and maybe a little sprinkle of magic.
So the work we do is becoming increasingly complex--different kinds of users, different form factors, different channels, different paths, different engagements.
This is Ted Nelson. He was pioneer in information technology and the originator of the term “intertwingularity”. Interesting side note, he also created the term “teledildonics”, which is pretty much what it sounds like.
But back to intertwingularity. Ted’s ideas have gotten more play in recent years and I think it’s because interesting problems, the ones that are worth working on, are really intertwingled. That makes them difficult to understand and even more difficult to “solve”.
These Magic Eye puzzles remind me of that moment when you’re working on something complex--whether because of it’s size or constraints or impossibility--and everything just crystallizes. When you can see all the planes and angles of a problem and you might even start to see how you could solve it.
It’s a magical moment.
I’ve been thinking about why those moments of clarity happen? And, whether it’s a skill you can learn more quickly that I have? Can you teach it to others?
At first I was skeptical that it could be taught, at least easily. It seems like a systems thinking perspective comes more naturally to some than to others of us. But I think we can learn and improve our capacity for navigating complexity.
Anyone got this one?
The title of this talk is “Systems thinking for everyone”. Actually it was “Ecosystems thinking for everyone” but the talk evolved in a slightly different direction. I hope you’ll bear with me.
So, what does systems thinking have to do with user experience specifically?
To be effective, I think we need to design systems to support experiences, not just interfaces.
Systems thinking gives us a way to design less fragmented, more integrated, end-to-end experiences.
I know this is a long list...but it gives a pretty good sense of the attributes of a systems thinker.
[Take a drink]
This is the kind of UX thinker I aspire to be. And the kind of thinker I’d love to hire.
Someone who sees the whole picture...changes perspectives...finds unanticipated consequences...holds the tension of paradox and controversy without trying to resolve it quickly.
So today, I want to share a few ideas for improving your capacity for systems thinking, and increase the same capacity in your clients and colleagues.
First, get your brain ready to handle complexity.
It’s like stretching before exercise or setting your intention before yoga. If you plop your brain (or your clients brains) into the middle of complexity without warning, you’re gonna strain a muscle.
I have a toddler and he starts talking about everything without preamble. He just jumps in wherever his brain is and sometimes it takes me a few minutes to figure out what he’s talking about. And, he gets really really frustrated when I don’t understand him.
In my own career, I have done the same thing. I’d come up for air from a project and just start talking really, really fast and intensely because I was really super excited. And the people I worked with, the dug their heels in. I felt like they balked at my ideas without even understanding them or, worse, they just zoned out. Which is pretty much the worst thing that can happen when you’re working on something complicated.
So, how can you help prime your brain?
First, Nobel-prize winning economists tested the way people actually behave, compared with the way über rational actors are meant to behave according to game theory. This is what they found: People gather limited information, reason poorly and react intuitively rather than rationally.
Economists are always so scoldy, right? But, let’s take an example: I have an irrational fear of a snake coming up the toilet. It was ridiculously easy for me to find this disgusting photo, a confirmation of my fear, despite the fact that I know that the odds of this happening are phenomenally slim. But, before you start feeling pious about those irrational people--people like me--we’re not total a-holes. In your own life and work there are situations when you gather limited information, reason poorly, and react intuitively rather than rationally.
But, it’s OK, we’re all in this irrational space together. That’s one of the things that makes us human, especially when fear is involved.
But how do you navigate this as a designer? The first step, I think, is awareness of and empathy for the invisible, powerful contexts that come to bear on systems. Your own context, your clients contexts, your customers contexts. Make those contexts visible (or named) and you will understand the system you’re designing much better.
Another strategy, and I think one of the most effective ones for priming your brain for complexity, is to PLAY GAMES.
Play games with your brain. Play games with your clients. And frame the activities as games because then the stakes are lower. There aren’t right and wrong answers. Everyone can look a little foolish and just relax a bit.
I want to share a few examples of how I’ve used games to prime the brains.
This activity is helpful for encouraging divergent thinking.
Have you worked on a project where it seemed like there was actually only one solution? Maybe your clients asked for options but there was never a chance for changing course. Or maybe when there is a terrible case of groupthink? Even as children, we’re trained to come up with the right answer, not the right answers.
One way to combat this is to
Take an everyday object, like a paperclip or a spoon, and ask everyone to spend a few minutes coming up with as many different ways of using a paperclip as possible. The emphasis on quantity first, not necessarily quality or feasibility.
This simple activity can help pave the way for being more open to ideating and flexible with solutions.
A second game is to use the 5 Whys.
This tool is especially helpful when you can’t put your finger on what’s actually going on? When you’ve been given a problem to solve and the layers of the onion keep slipping off as you go?
You start by agreeing to and writing down a specific problem. Then ask why the problem happens.
If the answer doesn’t seem like the root cause, ask why again? And so on.
Finally, I want to share a little about role playing as tool for priming the brain.
I’m working on a project with the Advising community at UW-Madison. They shared this current state/desired future state diagram with us.
After a few weeks of working together, it occurred to us that while we totally got how awful their current work flow was, we had no idea what they meant by “high-value” advising. In fact, we were acting a little smug with our air quotes.
We were already focused on decreasing time spent navigating and teaching systems but, how could we design something better if we only had a vague understanding of their desired future state?
So we asked them to role play, to act out scenarios, so we could see what better looked like. They’re usually pretty good sports but they were a little reluctant. I get it. Before doing it, the idea of role playing seemed LAME.
But, by the end of the activity, we had all learned a great deal about what plain-old advising looks like and we had some great ideas about what high-value advising might look like. Unfortunately, I wasn’t able to record our roleplaying but I will share a little snippet of a video that inspired the activity.
I don’t have time to show this video, but I hope you’ll check it out as a great illustration of how to use role playing to design interactions.
This is Stephen Anderson and the video is on YouTube. It’s called Roleplaying the Interaction.
Essentially, he asks this young woman to role play an online form. See she’s got a web browser cutout.
By acting things out, we get a better understanding of the humanness of user experience. And, like with improv, it helps you build camaraderie with your clients or colleagues.
These are a few ideas for priming the brain for complexity. There are lots of other techniques and I’ll include reference to one collection at the end of the presentation.
So much of our work is about cleaning up messes. And there’s a tendency, in the face of so much complexity, to immediately start simplifying, sorting, discarding right away. It makes our work easier. My clients frequently state a goal of “simplicity”, which I never quite know what to do with.
But in moving too quickly away from the discomfort and gift of complexity, we miss opportunities and devalue our work.
I recommend you chart your course straight towards complexity. Here are some ideas for how to do that.
I’m a UX practitioner and I skimp on discovery. Every time.
Why? Because it’s expensive, time consuming, and, it’s hard to convince clients to do.
But, without the raw materials that discovery provides, what happens? Despite our best efforts, complicated problems stay complicated. Or we solve the wrong problems. And, the worst part? Most of the time, we knew there was something wrong with the approach and execution all along.
So, do more discovery. Do as much discovery as you need to do to define the problem, your users/customers, your clients. It doesn’t have to be exhaustive research, just enough of the right kind. Even if you’re working in an agile environment, discovery can help you prioritize the backlog and establish a roadmap for future development.
Ask questions like: What problem does this solve? What evidence do we have or need? How will we know if we are successful?
In complex problems and systems, there is a tendency for things to get worse before they get better. Sometimes a lot worse.
This is profoundly uncomfortable for most of us. And especially so when it happens in front of a client or a boss.
When things get complicated, we get bogged down, we get defensive, or we rush to an answer. And, we ignore or hide the inconvenient flaws.
But complexity is a gift.
For one, it makes for more interesting work. For another, almost everything is actually complicated. If you avoid complexity, you may never realize that you’re not solving the right problem. Or that the problem and solution are actually much simpler than you originally thought.
Do the hard work to make it simple. That’s one of the design guidelines that folks at Gov.UK use. And it rings true.
Help your clients or stakeholders expect this complexity, and share it with you. When they see the tug of war that’s happening between different elements, they have much more empathy for the nuance of the solutions you propose.
And speaking of clients...
Sure, I’ve been frustrated when clients wouldn’t give things up, wouldn’t change their practices, or seemed to lose momentum. Maybe you know the drill, you meet every week or two and it’s like you’re strangers to each other and the project every time. Things drag on forever and no one’s happy.
To combat this, I would labor over fortresses of research, documentation, and “proof” to back up recommendations and designs. But the downsides were many:
Clients don’t appreciate the complexity of your solution if you haven’t brought them along with you.
I ended up putting more energy into deliverables rather than actually defining and solving the problem.
And, ultimately, products and services are co-produced by more people than you. If you design without them, you will probably design a solution that isn’t sustainable.
I wish I’d gotten comfortable with co-creation or collaborative design sooner because, even if it’s a little scary, it’s a really generous and sustainable way to design user experiences.
What does co-creation look like?
One simple tool to foster co-creation is the phrase, “How might we…?”
This isn’t a new approach, but it was new to me. And, I was skeptical that something so simple could have such a big impact. But, language is powerful.
Asking “how might we?” is open, optimistic, inclusive and future-oriented. It’s not “how can you?” or “how should you?”.
It’s safe for the commitment-phobes to pitch in and it re-routes the naysayers. And, maybe most importantly, it means you don’t have to have the answer, you don’t have to be the “expert”.
I want to share a co-creation story that began with a “How might we…?”
Just a bit of background about this project:
The process students go through to select and enroll in courses and plan their degrees...well, it honestly couldn’t get much worse, unless you were running around the animal stockyard the way students used to have to register at UW-Madison.
Everyone knows the process sucks but they just couldn’t seem to get unstuck enough to figure out how to make improvements.
A few weeks ago I facilitated a design sprint dedicated to answering this question: How might we create an intuitive and supportive enrollment experience that aligns with student and institutional goals?
We included advisors, students, subject matter experts, technologists, and designers. Around 25 participants in total. Most of the participants had never been a part of something like this before.
I should note that our process was modeled closely after Google Ventures Design Sprint Process, which is terrific, they’re very generous with how-to resources.
In essence, we spent an entire week developing a shared understanding of the problems facing students and then co-creating and testing a solution together.
The first day was all about introductions, getting to know each other.
Then we spent time learning about the current user experience and opportunities for improvement.
We reviewed analytics, observed a live student walkthru, heard perspectives from advisors, and then broke into smaller groups to optimize the user flow.
On the second day, we asked our participants to engage in divergent thinking.
Because the user story was fairly complicated, we divided it up into five, more manageable chunks. Every participant worked independently at first (to avoid brainstorm groupthink) and then came up with a storyboard solution for each part of the user story.
We hung the storyboards up and participants voted on the best ideas.
Honestly, divergence is a little terrifying. People come up with all sorts of weird ideas -- in fact, we ask them too -- and it’s hard not to panic when you’re surrounded by 125 storyboards. How the hell do you narrow that down?
But narrow we did...
...by seeking the conflicts or differences in our designs on the third day. Midwesterners are so funny about Conflicts...
We also stated our assumptions, which was unexpectedly powerful and revealing. It gave us a non-offensive way of saying, hey, what are we assuming anyway? Maybe we assume that students want to plan all of their terms, through to graduation, and not just the next one. Now we have a stated assumption that we can test with users.
Which brings us to prototyping.
On the 4th day of the design sprint, we cut most of the participants loose and a small group of us created a clickable prototype using Keynote and planned user testing for the final day. This was an extraordinarily long day, we worked until well after midnight.
But, from a prototyping perspective, it was fairly smooth sailing since we had answers to most of our questions and had nailed down the user story.
On the final day, we did user testing in the morning with six different students. This is a screenshot of a Google Hangout where we recorded and projected the user testing back to the design sprint participants.
After we wrapped user testing, we reviewed the results of the testing, and noted areas for improvement. I think we came up with a pretty good prototype considering how little time we had but, even more important, we build incredible shared understanding, camaraderie, and excitement.
You don’t need a week-long design sprint to co-create. There are other, more informal ways of bringing these practices to your work. That said, in my experience, doing something more intensive like a design sprint moves a project much further along than weeks of interruptions and status meetings.
Finally, I want to talk a little about trust.
What does trust have to do with systems thinking?
There’s a phrase that “Culture eats strategy for breakfast.” When I first heard the saying, I didn’t really get what it meant. Part of the reason, I think, is that strategy is really neat, it’s smart stuff, you look cool when you talk about strategy. And culture? What does culture have to do with strategy?
But, a recent bad experience at work made the expression click for me. And when I think back to the things that have gone wrong in my work and life...a lot of the weird shit comes back to a lack of trust, despite best laid plans.
Maybe it’s clients who stop, or never did, trust you. Developers who don’t trust you. Project managers who don’t trust you. Or the same going in the other direction--you don’t trust your clients, your boss, or your colleagues. And the more complicated the project, the greater the likelihood that there will be some trust issues. Lack of trust makes people miserable and it can sink a project.
So, invest in earning and building trust. It will pay dividends for everyone that works on the project.
How do you build trust? Many of the tools I’ve described today help: playing games, embracing complexity, and co-creating.
Another key technique:
Get out of the deliverables business. Unless you’ve already finished the project, you don’t really know what the deliverables are. So how can you develop a working relationship, let alone a contract, when you know so little? I still struggle with this one. I’ve written deliverables contracts for UX work and it just sucks. It’s so stressful and inaccurate and you’re stuck with whatever you guaranteed, even if doesn’t make sense. These deliverables contracts lead to distrust and resentment. I’m still developing a time & material contract that acknowledges that we don’t know what the solution is yet but we’ll work together to figure it out. If others have come up with better contracts, I’d love to talk.
There you have it. A few ideas for improving your capacity for systems thinking and hopefully designing better experiences along the way.
If there’s one thing I want to stress, it’s this:
Before jumping into a problem, spend some time thinking about it as though it were a system.
Invest energy in getting perspective, trying to get at the root of the problem, and trying some different techniques when you get stuck. And, try especially to think about the system you need to design to solve the problem.
Here are a few of the resources you might find helpful as you explore systems thinking further.
I’ll be here for the rest of the conference. I hope you’ll introduce yourself!
Thank you.
