Sign her up for the team!

I went into the break room this morning to refill my coffee and encountered something that struck me as a really effective UX. Good design can happen anywhere, you know?

Have a look at the scene below:

Break room signage

In addition to all the ordinary coffee and tea accoutrements there is a little yellow sign. It probably stands out to you, as someone who has never been in this room. And to me – someone who is in this room all the time – it was 100% noticeable the minute I walked in.

Now have a closer look at what the sign says. (The names and email address have purposely been obscured to protect identities.)

Break room signage text.

Message received, Chrissy. Brilliant!

Now why did I find this sign so delightful? Let’s break down the UX:

1. Chrissy obviously knows her audience. She picked a high traffic area that everyone in the company is bound to traverse sometime during the day. So the placement was perfect to get her message out.

2. Chrissy also knows that if there’s one thing that people are passionate about in the office, it’s their morning coffee, tea, or sodas. And when something breaks or runs out, facilities always hears about it in a hurry. So again, great idea to place the message here.

3. Chrissy also chose the perfect color: Yellow. It’s a bright color that stands out in the context of the darker coffee machines and thermoses. Yellow also has an association with a warning message for us software / web / mobile design people. It’s not red (critical!) or green (all good), it’s yellow. Perfect.

4. Last but not least, Chrissy chose a nice size and display for this message. It’s not overbearing or disruptive. But it’s easily legible from a close distance and the up-right frame makes it stand out in a crowded counter space.

I have to say, it gave me a smile. I was really impressed. “Sign her up for the UX team”, I thought.

I can’t wait to share this blog post with her when she’s back from her PTO. It should give her a chuckle.




“The opposite problem for some executives is that they can be too close to customers (for instance, IT managers who buy a solution) without understanding end-users (the people who actually use the solution on a daily basis) They get so much feedback from their sales teams that it leads to feature creep — adding features to satisfy every customer. Along the way, any semblance of a coherent user experience is lost. The result: a highly-reactive product development culture in which extra features are continuously bolted on, making the company vulnerable to more pro-active competitors who have a laser-like focus on UX, which can be a potent disruptor in many industries.”

– Robert Fabricant, “The Rise of UX Leadership“, for the Harvard Business Review

The Remote Control that gives people Fits

This is the remote control from the Mesquite conference room at our office:

photo 1

At a glance, it may look like any other remote control that you’ve encountered in your lifetime. But this thing gives people fits. Especially newbies. Why? Let me share a little scenario with you (a true story, no less) to explain.

1. User enters Mesquite conference room to host a meeting.

2. User plugs in his computer and picks up remote control to turn on wall monitor.

3. User clicks big red button on the remote: Monitor comes on.

4. User hosts meeting.

5. User unplugs computer at end of meeting and picks up remote to turn off wall monitor.

6. User clicks red button. Nothing happens.

7. User starts waving remote around at different angles and clicking red button again and again. Nothing happens.

8. People in the room after the meeting start laughing and offer a suggestion: “Maybe the batteries ran out?”

9. User takes batteries out of the remote, puts them back in, points it at the monitor and clicks red button again. Nothing happens.

10. User walks over to IT Help Desk with remote in hand and tells them it needs new batteries.

11. IT Help Desk staff search around for batteries for 10 minutes then replace them.

12. User walks back to Mesquite conference room and tests new batteries by pointing remote at monitor and clicking the red button. Nothing happens.

13. User walks back to IT Help Desk and tells them the remote’s still not working. IT assumes the batteries must be bad.

14. IT opens a fresh pack of batteries and replaces them in the remote.

15. User returns to Mesquite conference room, points the remote at the monitor and clicks the red button. Nothing happens.

16. User walks back to IT Help Desk and tells them the remote still isn’t working.

17. IT Help desk staff walks with user to Mesquite conference room and tries remote. Monitor turns off this time! IT guy smiles and points out something the user didn’t notice.

So what happened here? It turns out there’s a separate “OFF” button on this remote. The big red “POWER” button only turns the thing on. Not off!

photo 1b

Boy did I feel stupid.

Yes, I was the user in the story and that was my first time using the fancy new monitor in the Mesquite conference room. And I made that mistake several times afterwards — clicking the red power button to turn the monitor off — before remembering that first experience and locating the OFF button.

I’ve also watched a bunch of other employees and guests make that same mistake. And they also felt silly when someone else had to point out the OFF button.

Are we all crazy to expect the big red POWER button to turn the monitor on and off? I don’t think so. There’s a design principle at work here. You may have heard of “Jacob’s Law”, as in Jacob Nielsen’s Law, which states, “Users spend the majority of their time on other sites than yours.”

Jacob was talking about Web design and the fact that people learn design patterns and formulate expectations about how things should work based on their experiences on other people’s web sites, not yours. So as a UXer, you have to be aware of those patterns and expectations and incorporate them into your designs to produce something that ‘just works’ for the user.

My experience with remote controls was that when you see a red POWER button, you can use it to turn something both on and off. I double checked the remote for my TV at home. Yep.

photo 4

I took a walk to the other conference rooms in the office. Yep.

photo 3

It was only that one brand new fancy monitor in the Mesquite conference room that had a separate OFF button that worked that way. So I and the others who made the mistake weren’t stupid. Someone else was. 🙂

But seriously, there is a lesson here. I’ve seen people laughed at for making that OFF button mistake in meetings on several occasions. I saw a customer who was visiting make the mistake and have someone else in the room have to assist him. I’ve also seen people get frustrated after making the mistake several times over and over when they should know better. And they blamed the remote not themselves! “STUPID REMOTE! WHO DESIGNED THIS THING?”

Is that the reaction you want to get out of your users?

Think about that the next time you’re tempted to break convention. There are times when you can do that. And there are times that you WANT to do that. But if you’re designing something for universal usage and a convention already exists for how to do it, you may want to follow suit to produce the best result.



The difference between the right word and the almost right word is the difference between lightning and a lightning bug.” – Mark Twain


I feel the same way about a good UX…

‘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.



Managing & Team Work

I have the same passion for being a UX Manager that I do for promoting good design. I can definitely be happy as an ‘individual contributor’ (warning: business-speak alert) but for the last decade and counting my time has been equally divided between crafting good design and building strong UX teams staffed with skilled UX Analysts and Product Owners who can fly on their own.

I bring this up now because I’m lucky enough to have been a Director, UX; Senior Director, UX; and VP, UX over the past seven years. So when I talk about design, I’ll frequently be talking about projects that I help drive with or through other UX team members. Please keep that in mind as you read on…

Lumension UX Team, Scottsdale, AZ 2014

Being a good manager is an art in itself. There’s a basic formula I’ve developed for new UXers that’s consistently brought success:

  1. When filling a UX team position (UX Analyst or Product Owner in my case), give as much weight to the characteristics of a successful UX team member as you do to their resume and work samples. Is the person a good conversationalist? Can he or she size up the role and opportunity quickly and say how he or she will contribute? Did he/she do their homework to research your company / industry ahead of time? Can he or she be honest and own up to both strengths and weaknesses? Can he/she talk about areas of expertise and things they still have to learn? Spending time on getting to know the person as much as their past work provides the real insight into future success. I’ll often make a hiring decision based more on potential and what I see as ‘building blocks’ than on how slick a person’s resume or portfolio may be.
  1. Start with a solid training and orientation
  1. Set the person up with a strong support system including peers and other team members.
  1. Setup a series of 1:1 meetings for the first 4-6 weeks, then ask the person if he/she would like to continue?
  1. Back off at that point and trust the person to do good work and know how to leverage his/her support system, and when to escalate things to me for additional input.

Managing over a duration of time is another topic altogether. I could go on… Ask and I’ll be happy to do so.


Now the other part of ‘Teams’ that I want to talk about is team work: as in working as a team.

Long before Agile development got hot and took over the industry I would preach to anyone who would listen about what I called my “Big Brain Theory”. The idea was simple: Designers, or any other technology role for that matter, should never work in a vacuum. They are always better off work-shopping their ideas with others to see how they are interpreted (or misinterpreted) and to learn about what thoughts their ideas spark in others.

I like to bring my research and prototypes for review with a full cross-functional development team that included architects, developers, QA analysts, and yes, even technical publications. It’s pretty common for someone to see something I didn’t see or ask about something I didn’t think of or offer some new angle that I hadn’t considered. I take the feedback and go back to the drawing board then work-shop it again. And soon, after a couple of cycles, I end up with something that feels really good; really solid. Or – wait – more accurately, WE have something that we all feel good about.

That was the ‘Big Brain’ at work. It was the collective brain of the team.

Image created by Allan Bashah for Lumension UX team

Yes, I’ve heard about the ‘too many Chefs’ metaphor, but there are ways to avoid that. And I understand that you don’t have to workshop everything with everybody all of the time. But as a rule, getting team feedback is a good thing and I’ll stand by that.