This happens. The team is heads down, just trying to do work, to make things work, and then you realize it. Perspective is gone.
Recently I gave a couple of talks about usability testing and collaboratively analyzing data. There was a guy in the first row who was super attentive as I showed screen shots of web sites and walked the attendees through tasks that regular people might try to do on the sites.
Sweat beaded on his brow. His hands came up to his forehead in the way that someone who has had a sudden realization reacts. He put his hand over his mouth. I assumed he was simply passionate about web design and was feeling distressed about the crimes this web site committed against its users.
Turns out, he was the web site's owner.
This I found out at a break. When people started filing in from lunch to start the next session, this fellow appeared in my second session. I had time to talk with attendees, so I decided to approach him. "Hi. I noticed you were in my first session. Glad you're back. I hope the first was useful." He said yes, he had found it useful. But he frowned. "You look puzzled. Do you have a question I didn't answer?"
The bubble is insidious
"No," he said. "But it's clear that I have been -- along with a whole lot of other people -- out of touch."
"Oh? You got some insights today, already?"
"Some especially applicable insights, actually. The site you used this morning as your example is the site I work on every day." He gave a sad grin.
I knew this day would come. I would get caught out critiquing or running a demonstration on a site for which the owner was present. That day had arrived.
"I should have talked with you beforehand," I said. "The site has some classic problems. That's why I chose it as an example. It is one of dozens of sites in this domain that have similar issues. If I did or said anything that embarrassed you or your team, I apologize."
He sighed. "Not at all. You can't be embarrassed by something you weren't aware of." He went on, "We hadn't looked at the site at all from the point of view of users outside the organization. We've been in a bubble."
He actually seemed grateful. "Ah. That explains it," I said.
We chatted some more about the political pressures and the technology constraints that his team -- most teams -- faced in creating a great web site and maintaining it. There had been some usability testing on intranets and even on extranets. But it was a few years ago. And the audience for the public-facing web site was different from the internal-facing web apps.
Perspective comes from observing real users doing real stuff
The best tool for resolving disputes within a design team, for making design decisions based on data rather than opinion, is sitting next to someone who is a real person who wants to accomplish something as they use your design to do it.
Some people call this usability testing. Call it whatever you want (except "user testing"). You can make it simple or complex, but when boiled down to its essence there are three ingredients:
- Someone to try out your design.
- Somewhere to test.
- Something to study.
That's it. You can do it by the book, or you can do it very simply and ad hoc. The insights come from observing, first hand. I've seen just an hour of observation get many teams out of their own, customized bubbles.
Supporting great design: features of bubble prevention
Recently I gave a couple of talks about usability testing and collaboratively analyzing data. There was a guy in the first row who was super attentive as I showed screen shots of web sites and walked the attendees through tasks that regular people might try to do on the sites.
Sweat beaded on his brow. His hands came up to his forehead in the way that someone who has had a sudden realization reacts. He put his hand over his mouth. I assumed he was simply passionate about web design and was feeling distressed about the crimes this web site committed against its users.
Turns out, he was the web site's owner.
This I found out at a break. When people started filing in from lunch to start the next session, this fellow appeared in my second session. I had time to talk with attendees, so I decided to approach him. "Hi. I noticed you were in my first session. Glad you're back. I hope the first was useful." He said yes, he had found it useful. But he frowned. "You look puzzled. Do you have a question I didn't answer?"
The bubble is insidious
"No," he said. "But it's clear that I have been -- along with a whole lot of other people -- out of touch."
"Oh? You got some insights today, already?"
"Some especially applicable insights, actually. The site you used this morning as your example is the site I work on every day." He gave a sad grin.
I knew this day would come. I would get caught out critiquing or running a demonstration on a site for which the owner was present. That day had arrived.
"I should have talked with you beforehand," I said. "The site has some classic problems. That's why I chose it as an example. It is one of dozens of sites in this domain that have similar issues. If I did or said anything that embarrassed you or your team, I apologize."
He sighed. "Not at all. You can't be embarrassed by something you weren't aware of." He went on, "We hadn't looked at the site at all from the point of view of users outside the organization. We've been in a bubble."
He actually seemed grateful. "Ah. That explains it," I said.
We chatted some more about the political pressures and the technology constraints that his team -- most teams -- faced in creating a great web site and maintaining it. There had been some usability testing on intranets and even on extranets. But it was a few years ago. And the audience for the public-facing web site was different from the internal-facing web apps.
Perspective comes from observing real users doing real stuff
The best tool for resolving disputes within a design team, for making design decisions based on data rather than opinion, is sitting next to someone who is a real person who wants to accomplish something as they use your design to do it.
Some people call this usability testing. Call it whatever you want (except "user testing"). You can make it simple or complex, but when boiled down to its essence there are three ingredients:
- Someone to try out your design.
- Somewhere to test.
- Something to study.
That's it. You can do it by the book
Supporting great design: features of bubble prevention
Fortunately, my new friend stayed for the second session, in which I gave my recipe for supporting great experiences:
- Each phase includes input from users.
- The team is made up of people each with multiple skills from various disciplines.
- Management of the team is supportive an enlightened about the importance of the user experience.
- Everyone is willing to learn as they go along.
- The team has defined their usability goals and knows how they will measure their success.
Note that of the five attributes, two are directly about perspective (input from users; learning). Another two are about creating an infrastructure for getting and using that perspective (multidisciplinary team; setting usability goals). The remaining one (enlightened management) means there's support for getting and keeping perspective.
The importance of perspective cannot be overstated. Teams that meet with users regularly – every week or every month – turn out great experiences. Observing users regularly, at every phase of a design, gives a team evidence on which to make design decisions. More importantly, that act of being present with users, can bring the team together, enlighten management further, and give a needed break from the rarefied space most of us work in every day.
Get out of your head and into your users' .
