Using a ‘Traffic Cop’ to Quick-fix Design Problems

Back in October, IxDA PHX hosted a ‘Design Thinking Workshop’ as part of Phoenix Design Week 2014. I’m one of the local leaders who helped organize the event. We had over 100 people signed up, which was great. But when the big day finally came, we ran into a big problem: Nobody could find the place!

The meeting was at a relatively new Tech Collaboration Center in Tempe, right on Mill Avenue. Google maps could lead you to the address. But it was a three story building that wrapped around a corner and connected to other buildings on either side. There was no obvious entryway. Instead, what you saw was a Bank, a smoothie shop, a clothes store, and a bunch of other college-town businesses. The Tech Center was up above on the second story, and the door to the Tech Center was a nondescript metal door set back from the road that also served as an entryway to 3rd story apartments.

I myself wandered back and forth on the street several times before running into someone I knew who helped lead me inside. Thank goodness for her! And when I got in, I heard a similar story from others on the set-up team:

“Boy is this place hard to find!”

“I must have walked by the door five times before I figured it out.”

“I had to call someone who works here for help.”

I knew right away that our 100 or so guests would face the same problem. Thankfully I also knew a simple solution – one that I’d used before as a UX designer. It was time to play Traffic Cop!

Tony the Traffic Cop, IxDA Phoenix Design Thinking Workshop 2014, Tempe, AZ

I grabbed an IxDA PHX sign and hoofed it downstairs to the street to catch people as they walked by. Some of our guests saw me holding the sign and gravitated right over. Others I’d see wandering around looking confused and ask them if they were looking for the Design Thinking Workshop? Yes? Right this way!

It wasn’t the ideal situation, but being a Traffic Cop for 45 minutes solved the problem and got people into our event. And that’s all that mattered.

So how does this relate to the design world?

I once faced a similar situation with a CRM solution I was working on. The Engineering group had rushed a SaaS version of their installable CRM software into Beta in time for a big Partner event. I remember hearing about the project early on. There was “no time for design”, they said. We had to let the engineers crank on this one in order to meet the tight deadline.

Fine, I said. UX is busy with our own projects right now. But tell you what… How about we set up a user testing lab at the conference (we were going anyways) and get some of the Partners to test drive the Beta solution first hand?

Everyone liked that idea. Our Partners loved getting their hands on new products and giving their input. So we did it. And guess what happened? These seasoned veterans who knew our installable solution through-and-through couldn’t complete the most basic task of entering a new contact into the system. Nine out of nine people that we tested on the first day got stuck.

How could that be?

It turns out the engineers had to break up the workflow people were used to in the installable solution when they re-built it online. The SaaS solution had the users start the task in the same place they were used to, but to finish the task they had to jump over to another screen buried under a different menu. And nobody could figure that out.

We (UX) talked to the engineers and the Product Manager the first night after the testing and told them about the results. It was a bad situation. There was no time to redesign the whole workflow before release, but we couldn’t leave it how it was. Nobody could use it!

And that’s when it dawned on me. Let’s put in a Traffic Cop. We’ll insert a link right at the end of the first set of tasks that jumps the user to the other page where they can finish up. It’s not the most elegant design in the world, but it should do the trick. We knew from the testing that people were stopping right at a certain place in the UI and looking for what to do next. With a link to guide them, they’d be all set.

We had the developers add the link that night. And we tested seven more users the next day. Bingo. Seven out of seven completed the task!


In the real world, when the power goes out and the traffic lights stop working; or when there’s an accident or big event and traffic needs to be re-routed, they call in a Traffic Cop to help direct people to where they need to be.

In the design world, you may face a similar situation. It’s not an ideal situation, but you’ll have to deal with it somehow. If it happens to you, remember the Traffic Cop solution and see if that can help get you through.



Making usability problems real for project stakeholders

Sometimes the old techniques work best.

On a recent project, one of our lead UX analysts ran into a situation where some long-standing usability issues were impacting the success of a soon-to-be-released new feature.

Everyone knew about these UX problems. They were discovered in past Betas and user testing sessions and had also been reported by customers via feature requests and Support calls. But when it came time to decide on what’s in vs. what’s out for a release, they never seemed to make the cut. In fact, the lead UX analyst had just lobbied for some of these very issues to be included in the current release – but no luck!

So now that they were staring her in the face again she knew she needed to do something different to make the problems resonate with the project manager and project stakeholders. She crafted a usability test and invited them to attend. While some of her fellow sprint team members made it to the sessions (always a good thing) the product manager and stakeholders did not.

That’s okay. She had recorded the sessions. And when it came time to present the findings she showed them sample videos from the tests to really accentuate the difficulties that the users were having.

In the first clip, she demonstrated an issue with selecting multiple rows in a list. If you click anywhere outside of the tiny little checkbox icons you lose all your previous selections. (ARGH!) It sounds fairly innocuous in the grand scheme of building a feature – the user can just try again, right? But to the user, this seemed pretty ridiculous. He had to laugh as he tried over and over to make it work and kept missing the mark.

It was clearly a bad UX.

Usability test clip 1: User selecting multiple rows – but watch out! Don’t click too far away from that checkbox!


Usability testing clip 2: Users reaction as he loses his row selections by clicking a pixel or two outside of the checkbox. What is going on!!!???


In the second clip she showed a user searching for a custom list he had just created. The user wondered out loud, “Did I forget to click OK?” Apparently he thought he may have forgotten to save the list. He moved his mouse pointer to the area where the list was supposed to be on the left side of the screen. “I would expect to see something here” he said. But he didn’t think to click on the tiny gray chevron. It didn’t look clickable anyways. It looked disabled. But that’s where the list was hidden – behind the collapsed tree node.

Another bad UX.


Usability testing clip 3: User searching the screen for the new list he just created. (It’s hidden in a collapsed tree node.) Note the frown on his face as he scans the GUI.


I was in the room when these clips were shown to stakeholders. To the credit of the lead UX analyst, she wove them perfectly into her overall testing summary. The response was just what she had hoped for: Seeing the users made the problems real for project stakeholders and now they wanted to do something about it.

And that’s the old trick that worked so well to blow the dust off of those “old news” usability issues and make them new again. All it took was getting some fresh evidence and rolling the tape.

Remember this the next time you are trying to get a point across with your stakeholder / product manager audience: Seeing is believing.

A lesson in seeking input from your target audience, as learned from the movie ‘Pretty in Pink’

It’s crunch time again: Just one more iteration to go before code freeze in our next dot-X release. And once again we’re right down to the wire, hoping to get the marquee feature done on time.

A lot of work went into the design from a UX perspective. Customer calls, use cases, design reviews with peers in UX and Architecture, and even a preview of UI mockups with a key customer to get early feedback.

However, we just had the second-to-last sprint review (it was about a five iteration project) and seeing the feature nearly complete raised several concerns from the internal stakeholders. There are some places where they think users will be confused. And there’s a bigger, underlying concern that the feature won’t meet the users’ expectations.

After all that work the feature still seems a little shaky. But for the love of God, why?

I think I know the answer. And there’s a lesson from the movie ‘Pretty in Pink‘ that explains why. Well, the lesson actually comes from the making of the movie. Let me explain.

One of the great Brat Pack movies of the 80s: Pretty in Pink

A while back I read a book called, “You Couldn’t Ignore Me if You Tried: The Brat Pack, John Hughes, and their Impact on a Generation“. It was a perfect guilty-pleasure read about a bunch of iconic teen films from the 1980s like “Sixteen Candles”, “The Breakfast Club”, “Ferris Bueller’s Day Off’, and yes, “Pretty in Pink”.

Awesome guilty-pleasure book for anyone who grew up in the 80s or just loves these classic teen films.

For those who aren’t familiar with the movie Pretty in Pink (which should be nobody, come on!) it’s a teenage romance about a punky high school girl from the wrong side of the tracks named “Andie” who falls for a dreamy rich guy, “Blane”. Her best friend, a boy named “Duckie”, is secretly in love with Andie, too. Much drama ensues as Andie and Blane try to establish a relationship across social classes in advance of their Senior Prom, with all of their friends seemingly against them and treating them badly.

What I learned in the book is that the original script had Andie hooking up with Duckie in the end. It was supposed to be a tale of true love born of friendship vs. falling for the rich, dreamy, popular guy (aka the Prince Charming) and riding off into the sunset. Hooray for the underdog!

And this is how they shot the ending at first. But when they screened the film with the target audience the teenage girls threw a fit. “No, no, no! She can’t end up with Duckie! She has to get with Blane!”

The kids loved the rest of the movie but they hated the ending. And in the exit surveys, they ended up saying that they hated the film.

After getting this feedback, the filmmakers went back and re-shot the ending so that Andie would indeed get together with Blane and when the movie was finally released it went on to become a huge blockbuster hit.

So what’s the connection to UX and the big marquee feature that my company is trying to get out the door?

If you’re looking for a commercial success, there’s no substitute for getting direct feedback from your target audience on a ‘final version’ of your project . Final version being in quotes, of course, because the point is to get feedback and make the necessary changes before you release. And in our case, we haven’t tested a complete version of the working feature with users yet. So we’re left guessing at how things will turn out.

You can’t assume that just because you’ve met your ‘artistic vision’ that your project will automatically resonate with the audience. Sure, you know them well and you’re smart and creative and passionate and have done all the things you know how to do to make something great. (You have done that, right?) But in the end, they’re the judge of what works. They determine your success or failure. They need a chance to see what you’ve done and give their opinion.

So getting something to ‘Done’ doesn’t mean just finishing up all the work items in the backlog. It means putting it into the users’ hands and getting feedback. And planning a project doesn’t mean squeezing in a bunch of stuff that just barely fits into the allotted time and rushing it out the door. It means plotting out a schedule that delivers working features with time to get direct user feedback NOT JUST ALONG THE WAY (in each iteration) but also at the end, when everything comes together and people can get a feel for the totality of the work.

If you can do that, you’ll remove those nagging doubts and replace them with solid evidence that tells you that you’re on to something good.

So queue up that last round of usability testing! And get ready for real success.




‘The Questions’

So I found myself in one of those cycles not too long ago where some big projects were coming to an end. Woo-hoo! We’re ready to ship something! The teams were driving toward the finish line with just a few things to wrap up and there was generally a good vibe around the office. But like most offices, there was a big concern in upper management about productivity. We don’t want to see anybody sitting idle.

Soon the pressure was on to start up a bunch of new projects. But the problem was, we didn’t quite have all the beginning-of-the-project work done and ready to communicate to the teams.

No bother. They can get started anyways! Right?

Some people thought so. But very quickly I had UX team members dropping by my office to lodge their complaints.

Actually, not all of them complained. One went right to work designing the thing he was asked to design.

Good for him right?


The beginning of a project is a CRITICAL time for UX because that’s typically when we encounter the bulk of the assumptions that people make. And it’s our job – our mission in life – to check the assumptions.

You should never go straight into designing something without knowing the basics.

Oh, but that will take too long! We don’t have time to burn on research cycles! That dang UX is going to slow everybody down!

I’ve heard that before. But it doesn’t have to be that way at all. To get started, all you really need to do is answer two questions:

1)       What do we want to get out of this project?

2)       What does the customer want to get out of this project?

We saw such a pattern of teams starting up without addressing these two basic questions (I’m sure nobody else has ever encountered this) that we ended up doing a special UX team session on “The Questions”. One of the team members, Fergal Moynihan, created a PPT deck and hosted a team discussion on the topic to help get everyone focused.


Frankly, we were bad at starting projects at my company for a while. But that was no excuse for UX not to do their job. I told them to think about it as if we were working for an agency (we don’t). There are ‘good clients’ who are totally prepared when you meet with them. They know their goals, they know their customers, they know their competitors, and as you talk with them the vision for the project flows out like poetry.

But then there’s the clients who are totally disorganized. They’re vague on their goals, they disagree on priorities, they have specific solutions in mind before they’ve ever talked about the customer problem, etc. etc.

As a UXer in that situation, you don’t say, “Oh well, I guess I better just start designing something.” No! That’s when you reach into your bag of tricks and start extracting the information you need to make the project great.

Sometimes that data will come from the people right there in the room. Other times, you get contact info for others who can help you out and you follow up with them. But one way or another, you get the information. Because you need it to do your job.


To bring it all back home, what I talk about ‘The Questions’ I’m talking about the fundamentals of the project. You have to have a basic orientation on what you’re doing, why, and for who, before you can start designing or, God forbid, start building something.

It is VERY important that you don’t skip this step – regardless of the pressure or the situation.

It’s also very important to check assumptions at this stage.

If someone tells you, “I need a button that goes ‘Foo’ when I click it.” You don’t just say OK and then go design the Foo button. (That’s called ‘leading with the solution’, by the way, which is a big red flag telling you to dig deeper.) You ask why. And you probe for meaning. And you don’t stop until you understand the motivation for the Foo button and can agree that that is indeed the right thing to build. That, or … maybe you discover that there’s really something else you should be designing that lies behind that initial thought.

And that’s where UX can add real value.



If they’re going to cut scope, you’ve got to watch out for the ‘Mutant Potato Head’

In addition to facing very tight development schedules, we invariably find ourselves needing to cut scope from a project in order to meet the desired ship dates. At our company, we’re operating in a date-driven environment. I don’t know about you? But that seems to be the norm in my experience in spite of the more open-ended framework you hear about in the Agile books.

So if cutting scope is the reality, what’s a UXer on a sprint team to do? Well, let me start by telling you what NOT to do: You most definitely do not want to end up with a Mutant Mr. Potato Head on your hands.


I’ve seen it happen too many times. A person – usually someone not on the actual sprint team – starts going through the backlog and pushing things out of the release based on size (storypoints/hours) and personal opinion (“We don’t need that. That’s gold-plating…”) until they get to a point where what’s left fits the dates.

This may be followed by an announcement to the team: “We need to pull in the dates by a month, but it’s okay, I took care of it.” Or, “We’re not burning through the backlog fast enough so I went ahead and cut the fat from the project so we can make the date. We just need to finish what’s left.”

Now, you could say there’s a problem of encroachment here: It’s the Product Owner’s job to manage the backlog. Why is someone else going in there and pushing stuff around without consulting him/her? And you’d have a point.

But I say there’s a more fundamental problem that starts with the approach that was taken. When you need to cut scope – for whatever reason – the starting point isn’t to go looking in the backlog for what you can take out. The starting point is to have a conversation with the team, on behalf of the customer, to re-examine the goals of the project and ask, “How can we deliver value and meet the intent of the project in less time?”

UX needs to be sitting front and center when that conversation occurs.

But let me digress… You may be wondering, what does any of this have to do with a ‘Mutant Mr. Potato Head”?

That came from a conversation I had with the UX team after this exact scenario happened to us. I heard about the cuts after the fact. A UX team member brought it up in our UX team meeting and he was not very happy about it.

I sized up the situation and went to a white board to start drawing. “This isn’t the right way to go about it,” I told them. “They’re not thinking about what we’re trying to deliver to the customer.” (In this case “they” was the Product Manager and Architect, both of whom knew the project well but were not members of the sprint team with an intimate understanding of the feature-level designs. But they still went ahead and chopped away at the backlog when word came down that we had to bring in the dates.)

I drew an analogy for the UX team to help make my point. I asked them to imagine that we were a toy company and that we wanted to make a Mr. Potato Head doll to sell to the kids. (My daughter was around 3-years-old at the time and we had a Mr. Potato Head at home, so it was the first thing that leapt to mind.)

Now say we came up with the design and we’re all happy with it and it’s been kid-tested, mother-approved – so now we’re ready to build. But as we start building things go wrong and we’re running late. We need to cut back from the original scope in order to deliver something on time. But what do we cut? Well, we could just start hacking away at the backlog based on sizing, but that may produce something like this:

Mutant Mr. Potato Head

Do you think a kid would like to play with that? It’s actually a little creepy and scary isn’t it? But hey, we can hit the date so who cares. Our work is done here.

Not right.

If we were to take a step back and reconsider the project goals: Let’s make a fun toy for kids to play with that lets them design the character and make it different each time. What could we do?

Well, first of all, you have to have the body. Everything depends on the body. And notice in the Mutant Mr. Potato head above, there’s only one foot. The thing won’t stand up with just one foot! That’s no good. You need two feet. Okay, now what? How about a face? Two eyes and a mouth will do it. A nose would be nice, but we’re pressed for time. Maybe it’s more fun to have a hat or a silly hair or something else to put on top. The top is kind of flat and weird without something up there, so yes, that’s a good idea. We’ll go with a hat and not a nose.

Now what? That’s all that fits. We’re at maximum capacity. Okay … But think about it. It doesn’t cost us anything to put the extra holes in the body where the parts click-in. We can put all the holes in and then the kids can move parts we’re shipping with around to silly places. And shortly after the product is launched we can have a follow-up project to produce a ‘Parts Pack’ that we can sell in stores that adds all kinds of fun things the kids can add to their Potato Head. And we can charge extra for that! Hey, we didn’t even think about that idea the first time around…

Okay, it almost sounds like we planned it this way from the start. Cool. We have a project. So don’t build the ears or the bow tie or the nose yet. Instead we’ll do the eyes, mouth and head. And definitely the body and feet. And we’ll add the holes where all the new parts will go. Perfect! Now witness the difference between our new plan vs. the old Mutant Potato Head plan.


And all it took was a conversation.

So the sad news is, in the original story where the Mutant Mr. Potato Head example came from – we did ship a bad design. The fact that the cuts were already made worked against us. It was too hard to get the powers that be to go back and revisit the work. And we paid a price in future Tech Support calls. So we learned our lesson.

Now whenever we face a situation where cuts need to be made the UXers in the group always call out, “Watch out for the Mutant Potato Head”. It makes people laugh, but hey, they remember it. And it leads to having the conversation up front before making decisions which produces a better result, proving yet another way that UX can help provide value.

Designing in an Agile World

The earliest process I knew as a designer was no process at all. That was my job at the Racing Form where in addition to managing the company news site we ran a Web hosting service for a dozen race tracks and bettor’s information services spread out across the country. We built each site by hand. I did the UI design and client-side coding and two other talented guys did the back-end stuff.

The first formal process I encountered was at my next job working for a snazzy Web design agency. To paraphrase comedian Steven Wright, it didn’t go something like this, it went exactly like this:

  1. Discovery
  2. Analysis
  3. Design
  4. Development
  5. Testing
  6. Launch

It sounds waterfall-ish but we kept the documentation light and put an emphasis on small teams working closely together, so it worked. I remember the “Process and You” training session they had us attend to this day. It was based on an old-time elementary school theme and they handed out three ring binders and cardboard pencil boxes to everyone. I think we even got Bazooka Joe bubblegum.

We did the waterfall pretty much full-on at my next job after that. I wrote 100-page Functional Specs like they were going out of style … and then they did.

Now everything’s Agile. Scrum. Kanbaan. DaD. I’ve done all of those and in each instance I’ve watched the teams struggle at the beginning to get things right. The people who kept an open mind and were willing to learn mastered things soon enough. But the dinosaurs (as they came to be known around the office) who wouldn’t inspect and adapt were serious obstacles and prevented some teams from gelling at all.

But what about UX? I was in a Director, UX position when we first attempted Scrum. I read some case studies. There was one at Yahoo that stands out. And something at Ericsson. I knew it could be done in spite of what I heard from some nay-sayers in the industry.

To me, it boiled down to this:


And Scrum (like all of the other Agile methodologies I was reading about at the time) came with a BUILT-IN customer focus!


At least in theory.

What we, the UX group, found on our Scrum projects was that the teams would often gloss right over the customer part of the process and jump straight into building something, which was usually whatever the Alpha dog engineer wanted to do or what the Product Manager told them to do. UX wasn’t consulted until the end and UX weren’t even members of the sprint team back then, so they had no visibility. When we were called in it was usually to “have a look at the UI.”

This was not good for two reasons:

  1. This put us in the age old position of having to explain that UX ≠ UI; something that Eric Flowers addressed brilliantly in what’s become a semi-famous write up in UX circles.
  2. Something that I was quoted on in UX Magazine came blasting out of my mouth when encountering this situation: “The same thing can be said about UX that is said about QA: You can’t just add it in at the end!”

An interesting thing happened as the UX team worked on changing this equation: 4/5ths of the team ended up become Product Owners on their Sprint Teams. That’s amazing, isn’t it? In many cases, it was a majority of sprint team members who basically elected the UX Analyst to take on the PO role. They wanted them involved. But what happened was our ability to do real UX work – to interview customers and analyze competitors and test things with users – was greatly diminished. The Analysts-turned-POs were too busy with their PO work in the sprint.

Ironically, I found myself promoted to VP, UX around this time and yet I was looking at a team that had pretty much no capacity to do the UX work that I was hired on to do. My plan was to change the org chart and add a specific UCD research branch, like this:

ux-department-vision-org-chartBut that never came to fruition. To this day, I still have half the team entrenched in the Product Owner role and another half doing the UX Analyst work. I think that’s okay … But I’m still pondering what this all means.

So in the end (it feels like it’s time to wrap on this subject), here’s what I have to say about designing in an Agile world:

  • The built-in customer focus is an advantage, but you must get everyone on-board to REALLY follow through on this commitment and resist the urge to go straight into building something without ever talking to a customer.
  • I still think that the UX analyst belongs on the sprint team as a team member and that they can only do their best work when mixing it up with others real time and in person vs. testing something after the fact.
  • What’s worked for us is to do our UX homework up front regardless of whether or not the time is given on the project, which includes demanding to meet with customers or customer proxies and to enter the Agile workflow with a CLEAR AND CONCISE understanding of what = success from a user perspective.

Let me crib a recent example from a team member. This is what Fred Hall, Sr. UX Design Analyst, put together at the onset of his project. I had a pretty big hand in this as well, and I’m proud of the outcome.

[Link to PDF to be added later.]

What I kept preaching to the team around the time this was created is that it’s their responsibility to develop an intimate understanding of what = good design on the project. And they have to back that up with research that includes customer / market feedback. And finally, I told them it’s their job to present this to the other Sprint team members and to make it visible so everyone knows it and can keep their eye on the prize.

For Fred, it came down to this one slide:


This slide made it into the stakeholder presentations at the beginning of the project. It was also used as a point of reference for the team to keep pointing back to along the way. Everything they did traced back to accomplishing these three things. The customer focus was crystal clear.

And that, to me, is the first major responsibility UX has when designing in an Agile world.

(More on this topic to come.)