UX: It’s not just a good idea, it’s the law

Last week, a developer asked me to look at some UI he was working on. It was a settings screen, and in certain scenarios a configuration could fail causing an error that required the user to re-run a synchronization. (I’m oversimplifying for the sake of the example.)

The design looked something like this:

sccm-01-main-settings-screen

What was bugging the developer was the fact that the error message got displayed way down in the left-side column, and yet to remedy the situation the user needed to click a command link way up in the top-right of the screen.

Would users know what to do?

Probably not.

sccm-01-main-settings-screen2

I told him that his instincts were right on. It was a classic Fitts’s Law scenario. “What’s Fitts’s Law?” the developer asked. And I gave him a Cliff’s Notes explanation, saying that it had its roots in ergonomic studies but that to us UXers it basically translates to saying that the closer an interface element is to an action, the easier / more efficient it is for the user to act on it; and, conversely, the further away the UI elements are from an action, the more difficult / less efficient it will be for the user.

So in the case of his UI example, we decided to repeat the command link inline with the error message so that it would be easier for users to identify the action and proceed to the next step of fixing the problem. (We didn’t actually do it in yellow, that’s just a mock up for this blog.)

sccm-01-main-settings-screen3

This encounter led me to Tweet: “Fitts’s Law easily gets buy in from people in our dev org. What other UX laws are out there? Must investigate.”

With the help of my fellow IxDA Phoenix leader Wayne Neale, I uncovered the following:

Fitts’s Law

In a nutshell: To recap from above, the closer an interface element is to an action, the easier / more efficient it is for the user to act on it; and, conversely, the further away the UI elements are from an action, the more difficult / less efficient it will be for the user.

How this applies to UX: Proximity matters! When crafting your designs, pay attention to the workflow and place action buttons, command links, navigation elements, etc. close to where you expect the user to be in their journey across the UI. This will make actions more intuitive and help the user complete tasks more efficiently.

Link: http://en.wikipedia.org/wiki/Fitts%27s_law

 

Jakob’s Law of Internet User Experience

In a nutshell: Jakob’s Law states: “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.”

How this applies to UX: If there’s an existing UX convention or pattern that applies to what you’re designing, you may very well want to use it – because this is what the user will expect based on how everything else works (in their experience). And when something doesn’t work as expected, users may get confused or, worse, frustrated, and decide to bail on your Web site, product, service, etc.and go to something more familiar that they feel comfortable using.

It’s your responsibility as a designer to educate yourself on design conventions and have a very good reason / purpose in mind when you decide to break them.

Link: http://www.nngroup.com/articles/end-of-web-design/

 

Hick’s Law, aka Hick-Hyman Law

In a nutshell: This law essentially states that the more choices you are given, the longer it will take you to make a decision.

How this applies to UX: Hick’s law is often applied to navigation and tool bar menus, but it can also apply to option fields, check boxes, and other elements presented on a page or in a form. As a designer, knowing about Hick’s Law can help you make decisions about how to segment navigational elements for the user – possibly using inductive design to narrow down top-level navigational options and present second and third tier items later, as the user drills down. It can also bring focus to workflow design: What is the user doing on a screen? What’s the main purpose? What are the main decision or action points? Distill things down to make things clear and your users will thank you.

Link: http://en.wikipedia.org/wiki/Hick%27s_law

 

Miller’s Law

In a nutshell: Miller’s Law is rooted in psychology and it basically says that the average person can hold up to seven things in their mind, max, before becoming utterly and totally confused.

How this applies to UX: Think about complex tasks involving multiple steps: Will the user be able to follow along? For how long? If you take Miller’s Law and apply it literally, you’d have up to seven steps and then that’s it – you’re going to lose people! But a better way of applying this may be to look at complex tasks and “chunk them up” into smaller objectives that the user can complete bit-by-bit on their way to accomplishing a bigger goal. A classic example of this is Turbo Tax. Their UI guides the user through the process of completing their yearly taxes, but does so in sections that the user can go through and complete one-by-one in sequence. The user can stop and come back, jump ahead, move backwards, and so on at their leisure. This was a very conscious decision on the part of Intuit’s design team and it took a task that most people hate and are fearful of (doing your taxes) and made it relatively simple, dare I say, easy?

Link: http://en.wikipedia.org/wiki/Miller%27s_law

I’m sure there are more UX laws that I’ve missed, but that’s a good start. If you know of any off hand, please reply in the comments!

 

 

A One Man Wolf Pack

Are you the only person doing UX in your organization?

For the better part of my career, I’ve had the privilege of working in UX departments alongside others who do what I do. I’ve also had the privilege of leading a large, international team of UXers for 7+ years. But at the moment, it’s down to just me. The lone UXer in the company. Or as I jokingly refer to myself, “A one man wolf pack“. (Yes, in reference to the movie The Hangover.)

Being a team of one comes with some serious challenges, bandwidth being the biggest and most obvious. But in my case, its also helped bring into focus some of the most important aspects of the job. I won’t claim to be an expert at this just yet. But I would like to share a few thoughts on being an effective solo UXer. Here it goes, fwiw:

10 Thoughts on being an Effective Solo UXer

1. Don’t wait around for projects to come to you.

2. Beware the squeaky wheel.

3. Develop your sixth sense of customer value.

4. Prioritize your work based on the BUSINESS impact.

5. Be creative in your engagements with Dev teams, Product Management, etc.

6. Don’t be afraid to let others drive design with you.

7. Know when it’s essential to be directly involved in a project.

8. Connect with UX associations like the IxDA, UXPA, etc. to stay grounded.

9. Stay cool, be friendly, keep positive, take a deep breath.

10. Always create value.

I could write a few paragraphs explaining each one of these in detail, but glancing over the concise list above – I think the main messages come through. If there’s one theme that weaves them all together, it’s being proactive in the work that you do. Inserting yourself into situations where you can add the most value to the project and the business is what it’s all about.

Oh, and by the way… I won’t be a one man wolf pack for much longer. Believe it or not, the guy in the middle of the picture below is joining the UX team this week to help out. No joke!

 

IMG_9491
Alan, Allan, and Alan.

Over and out.

Quote

“There is a lot of discussion and articles about usability and functionality of websites and applications. Functionality, of course, is important. For example, what good is an airplane if the engine isn’t powerful enough to get it off the ground? If you take a step back though, the more important question should be: How far does the user need to go? If it’s only a few miles down the road, then it really doesn’t matter if the plane is functional, it’s the wrong solution altogether. So, discovering what we really need to build is a key in the initial phase of building the user experience.”

– Fancisco Ichauste, “Better User Experience with Storytelling – Part 1“, Smashing Magazine, January 9, 2010

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-IxDA-PHX-DW-2014
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!

crm-workflow-traffic-cop

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.

 

QUOTE

“The number one thing you can do to make people care about UX is to make them watch their users.”

– Jared Spool, 10/17/14, Small group meeting in Scottsdale, AZ during Phoenix Design Week 2014

A Meeting with Jared Spool

Jared Spool was recently in town for Phoenix Design Week 2014. I was invited to meet with him as part of a small group session at the Tallwave / Ethology / 29th Drive offices in Scottsdale.

Everyone who reads this blog should be familiar with Jared and his work. This is a UX design blog after all and he’s kind of a big deal! But just in case, here’s a bio that they posted on the PHXDW web site:

jared-spool-bio-phxdw2014

 

Jared did not disappoint. In addition to being a beacon of UX knowledge and experience the guy is quite a character and he was ‘on’ from the minute we arrived.

He broke the ice with a joke about dealing with The Cloud on his plane ride into Phoenix. He said that he was very frustrated … There he was, literally right up in the clouds and yet he could not access his data. Har-har.

Here are a few more highlights from the meeting. Some of these are direct quotes, like the ones about Empathy and Design Thinking. In other cases I’ve paraphrased what he had to say.

Enjoy!

 

Jared on the role of a Senior UX Designer…

“I visit these companies all over the place and when I walk in I see Senior designers wasting their time doing mock ups and wireframes.”

That struck me odd, so I asked him, “What should the Senior Designers be doing instead?”

His response:  “Figuring out how design will increase revenue. Figuring out how to increase customer satisfaction and attract more business. Let the junior designers do the grunt work.”

 

Jared on building UX within an organization…

 “It’s a DNA thing. Companies either get it or they don’t. It’s like the circus. Have you ever heard of Ringling Brothers? They roll into town, put up a tent with a few animals in it, and they roll out. There’s nothing elegant about it. But then look at Cirque du Soleil. It’s obvious that the founders had an exceptional experience in mind. And that’s what they sell. They sell fewer seats than Ringling Brothers, but they sell them at a premium. They make more money by selling a great design. And that’s their choice. You’ll never see Ringling Brothers doing that.

Apple is another example. It wasn’t always that way with Apple. They put out a lot of crappy products for a while. But then there was a culture change. And EVERYBODY in the entire organization was bought in. That’s the only way you can do it. If everyone is bought in from the Executive team on down.”

Someone in the room asked, “What if you just have a single champion (who values UX) on the Executive team?”

Jared’s response: “Can that person fire all the other executives who aren’t bought in? No? Then it won’t work.”

 

Jared on knowing when a product is ready to ship…

 “What’s the test [to know when something is ready to ship]? Does everyone in the organization know what the test is?

Let me tell you a story about Steve Jobs. When Apple was working on the iPod Nano or whatever – an early iPod something – they brought a prototype into his office. Steve Jobs told them that it wasn’t small enough. They argued that it was as small as it could possibly be given the technology they were working with. There was nothing else they could do. Steve Jobs had a fish tank in his office, so he took the prototype over to the fish tank and he dropped it in. As it sank to the bottom these little tiny air bubbles came floating up to the top. ‘See that?’ Steve told them. ‘There’s air in there. That means there’s extra space that can be removed to make it smaller.’

They went back to the work on it and they did come up with something smaller. In the meantime, Steve Jobs had fish tanks installed throughout the entire office. It was a reminder of the mission.

So at Apple, it was Steve Jobs. He set the bar for when something was ready to ship. Who has that role at your company? Who owns the definition? If you’re not sure, and if your whole company doesn’t know it by heart, then you’re in trouble.”

 

Jared on Empathy…

“If I hear one more  f***ing talk about empathy, I’m going to kill someone.”

 

Jared on Design Thinking…

“I want to see less Design Thinking and more design doing.”

 

Jared on where the industry is going when it comes to hiring UX…

“What companies are looking for is Unicorns. You have to be able to do  it all. You have to do the UX research and the prototyping AND write some front-end code AND work with a team to build it AND be able to do some user testing and iterate. You have to do it all. But there’s not enough people out there who can do that.

24,000 jobs. There are 24,000 UX jobs open right now … and not enough people to fill them. That is why I started the Center Centre. We’re going to train people in all of these things so they can take on these jobs.”

 

Jared on innovation and problem solving…

 “I was in a room at this one company that was filled with smart people. This was going to be our project team. You had your Architect and your  Engineer and your QA and they were all very bright and talented.

As we were talking all of these great ideas starting to come out. There was no shortage of things that we could do. The only time we had trouble finding a solution was when we didn’t know what the problem was.

It became very clear as we moved into the kick off that the business couldn’t state what problems it was trying to solve. And so we had to back up and figure that out. Because it doesn’t matter how smart your team is – you won’t be successful solving anything if you can’t identify what the problems are.”

 

[ End of Post ]

 

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.

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

 

CPL-usability-grab04
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.

 

CPL-usability-grab02
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.