Introduction

You know a book title has something when you stare at it. Just staring means it grabbed your attention.

Do you remember the phrase "pay attention"? If means that if you get someone's attention, it's worth money. Think "Paris Hilton".

Now think "usability". Pretty boring, eh?

And that's the problem.

Or, it was the problem until Alan Cooper invented the eye-popper title for his usability manifesto: "The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity".

This introduction reflects our mutual problem: "Why can't I get our management to jump on the usability bandwagon?" You and I know that usability solves big problems. Yet we still face challenges getting project time, developer commitment, and end-user access to do our job.

Let's investigate the madness of it all. At least it's more interesting than just plain old "usability".

The logic of bad design

What holds your organizations back from committing to usability as a method? I recently received an email from a former course participant asking how to solve this problem.

(His CUA certification got him a new job with the following challenges.) He wrote:

1. "So this is the product we sell and use internally – and this is where I come in to make this product more usable. One of the problems is that there are mixed expectations – the CEO wants me to make everything very new and cutting edge (we want to have what Microsoft has just developed) and they also want me to help them make <software name> more usable.
   
   (Logic of Bad Design: The boss wants usability but also wants design changes so fast there is no time to study our users, develop scenarios, invent better solutions, test and iterate.)
   
2. "Like I said, this product has always been developed with technology as the main aspect – it has to do this, or the clients need this functionality. "
   
   (Logic of Bad Design: The boss wants me to add functions but allows no time to think about other user groups and no time for usability testing that might find "unintended consequences".)
   
3. "The screens are cluttered with buttons and menu bars, where if you need to export something you need to select a button in one of these bars."
   
   (Logic of Bad Design: The boss says, "It's based on how Microsoft Office was designed.")
   
4. "...It's a hell of a job – especially because I am "dropped in" after 15 years of other people developing and using the product – and they expect me to take my magic wand and fix it."
   
   (Logic of Bad Design: Colleagues say, "People have always bought our software. Changes will scare users away. We must code now.")

How do you answer these problems?

Escaping the logic of bad design

Our challenge is clear. How do we break through the self-created prohibitions that trap the unwary manager in a downward spiral of misperception?

Normally, I would cite some research that addresses our question of the month. However, after looking though all my usual sources, I couldn't find a pragmatic answer.

Consequently, I looked at how HFI's founder Eric Schaffer addresses these hard problems. Interestingly, the questions asked by my former student received fair treatment in Eric's blogs on HFI Connect.

In essence, Eric proposes that management must "institutionalize" usability – making it the standard practice rather than a special treatment.

Let's see what that means for all of us struggling to leave the asylum. (Remember Alan Cooper?)

The next four points answer our CUA letter-writer with pragmatic solutions to management's logic of bad design.

1. Loving the madness of good design – the bandwagon effect works

Eric's comments from 1 Feb 2010 address our CUA's first Logic of Bad Design: the boss wants usability but also wants design changes so fast there is no time to study users, develop scenarios, invent better solutions, test and iterate.)

I started work on my book, Institutionalization of Usability, in 2001. I wrote it because I realized that our field had to mature. We were clearly proving our worth. By showing the ROI of usability, companies would want to have it built in as a routine part of their development process. And they would want a process-driven process.

I blame piecemeal usability as the source of the oscillating UX group. The group gets hired. Then they run around frantically because they are perhaps 2% of the staff strength needed to operate properly, and they are operating without the infrastructure and acceptance that makes us efficient. Pretty soon the question comes; "Are they worthwhile? What do THEY do?" And of course there has been no time to prepare contrast studies and documentation of the value of the work. The team is disbanded at the first budget reduction. Then there are slowly growing complaints and a team is put in place. Then repeat. It's awful.

So we need to be built in as an organized part of the SDLC. And we need to be "PROCESS DRIVEN". That means that we don't depend on a couple of brilliant craftspeople to do magic (and train a few apprentices). It means we accomplish UX work based on normal, systematic engineering processes. Jared Spool and I debated about 5 years ago and he asserted that UX was only ready to be done by craftsmanship. It was a bitter if very friendly debate (and I think he was really on my side). But now we have proven the possibility, and companies are jumping to make UX work routine.

---

Eric just pointed out that usability has become popular. Managers who find solace in following "general practice" of the herd now find the herd galloping towards usability. In a sense, this IS the solution we need. Of course, we also need diplomatic evangelism to encourage early adopters amongst our manager audiences.
Solution: Show your managers articles (and blogs) that discuss trends such as Eric describes next.

---

Worldwide we see companies who understand that it makes sense to do UX work right the first time. We are seeing the end of fixing train wrecks. We are seeing a transition away from emergency and chaotic UX. We are seeing more clients then we can manage ask for help setting up those organizations. They understand that it requires executive sponsorship. they understand that there must be a roadmap to setup the organizations, communication channels, staff resources, culture, methods, standards... etc. They understand that panic is not efficient.

So, I'm willing to bounce around the world for awhile as I see a dream come true. When I started in 1976 it was truly unimaginable. The level of executive support we have today is fantastic. In fact the biggest problem is often that there is LOTS of support in a massive pileup of cross control and confusion.

But...the plane is boarding. I promise to write more later.

2. Be a broker between the vision and the doing

Our second Logic of Bad Design lamented that the boss wants me to add functions but allows no time to think about other user groups and no time for usability testing that might find "unintended consequences". On his 8 Feb blog, Eric shows how to co-opt management goals as usability goals.

The executive team sits at a table with a set of stakeholders. Some, like information technology have a long established seat. Marketing has a seat. Even Quality has a seat. But can we sit there? Can we help guide the future of the organization? Well, the answer now is "YES WE CAN".

I have institutionalization of usability clients in India, Australia, The Philippines, and Africa. These are places you might think would lag behind. But, NO. The executives all get it. They understand that usability and customer-centricity in design of their applications is a critical differentiator. The executives understand that user experience matters!

The challenge is that the table is a zero sum game. When we sit down we take a share of the resources and that means less for others. In that, we have a challenge. How can we gain acceptance from marketing, technology, strategy, etc? I spent all of last week at such a table, and I will share the winning strategy.

The insight that won the day for the UX side was a simple idea. The fact that UX design had been absent meant that 'THE Executive', Strategic Marketing, and Strategic Initiative groups were all DISEMPOWERED! Their ideas never reached the design and coding group because they could convey their ideas (e.g., "We need to reach out to youth, changing our brand and fitting in their lives").

But, the design team had no idea what that really meant. It is only when the UX work takes the strategic intent and converts it into innovative ideas and specific designs that the connection can be made. UX is the 'golden chain' that connects the strategist's work with the coders. So, there are a whole set of people who we make effective. And when you make others effective, they want you at the table.

---

Eric tells us how to go to "charm school". Make friends. Appreciate their genius. Help them attain the goals they have. Remember, usability is not their thing. But strategic business is their thing.
Solution: Adopt the vocabulary, metaphors, goals, ideas of your management. Talk their talk, not usability talk.

---

When I started working with Institutionalization clients, I thought what was needed was an executive champion. I wrote about executive champions and my experience was that there is usually someone at a high level who drives each effort. To an extent, this is still true. But, I find that in large organizations there must often be a whole SET of champions. It is not just the individual executive on her throne. It is a table full of leaders.

When we work on programs to institutionalize usability we pay attention to governance. Without a seat at the table all the efforts will eventually fail.

3. Madness is the courage to do it right, even if it's "different"

Our third Logic of Bad Design rationalized keeping the old design because the boss says "It's based on how Microsoft Office was designed." In his 28 Feb blog, Eric says:

Of course, the experts are not as detrimental as the person pretending to be an expert. There is a huge systems integrator in India...I keep getting called in by their customers because their software is so very unusable. They have low prices. They code nicely. But, they have horrid interface designs. Remarkably, they have a UX team, with about 50 people! So how can they have such awful designs? I was intrigued by that.

On closer investigation we found that the head of the organization is a graphic artist who was briefly exposed to HFI many years ago. He has acquired enough of the UX language to talk about the field. But he was never actually a qualified practitioner. And now the dynamic appears to be that he is carefully hiring only staff who are even less qualified then he is. It seems he is afraid of being shown to be technically weak. So he avoids strong hires and even strong consultancies. He does not understand that the power of a strong leader is in having people in the organization that are technically better than himself.

---

Eric chides leaders who feel they have design expertise. After all, would you tell your surgeon how to tie the sutures for your appendectomy? If fact, do you insist on watching the video of your brain surgery to insure they excised the tumor correctly? Of course not.

However, managers who evaluate your designs by looking at your prototypes commit the same fallacy.
Solution: Support your manager's quantitative business goals with your own usability metrics. Present and talk about your metrics for user success: faster learning, faster productivity, and greater feelings of success. At some point, you may even ween your management off of looking at the screens – after all, you demonstrate their value with your metrics. Eric concludes:

---

I have never seen a leader deposed for building and motivating a strong team. Leadership is actually not about how well you can do the work. It is your ability to glue the team together and appreciate (even celebrate) work that is better than you could ever do.

In the end, I think that the head of the UX operation need not be a super expert in the field. Passion for the field is essential. Some knowledge is essential, but can be acquired. The key is having someone who can provide leadership, who understands the organization and can find the right people and the right issues. Get someone who knows how to make friends and knows how to fight politically if necessary. And then a strong technical team can be filled in underneath.

4. Embracing the madness of the institution

Recall the final lament of our CUA warrior: "It's a hell of a job – especially because I am "dropped in" after 15 years of other people developing and using the product – and they expect me to take my magic wand and fix it."

We identified the logic of bad design: colleagues say "People have always bought our software. Changes will scare users away. We must code now."

What's your diagnosis?

Our final word comes from HFI's "Institutionalization Self-Rating Scorecard". I answered the questions to mimic our CUA's conundrum. Here is the diagnosis for the institutional solution.

You scored 13 out of 39

You've made some progress towards institutionalization of user experience in your organization.
Here is what you need to concentrate on to improve:

• You need to attract an Executive Champion: A Person in a high place in the organization who champions the needs, existence and work of UX and the UX team. Someone who is at a VP, Director, or C-level so that they can be persuasive in the organization.
  
• The Executive Champion has to have a written strategy for both the short term and long term plan of user experience in the organization.
• Work on the training and professional development of your user experience staff. It's important that your user experience staff is well trained and has the opportunity to continue to expand their skills. It's very helpful to have people on staff who have had specific usability, user experience, human factors training through a regular advanced degree program, (for example, a masters degree in human-computer interaction or HCI).
• At least, and in addition, all your user experience staff should take basic courses in usability and user experience and be able to demonstrate competence in the field. In addition, there are high quality training courses and conferences in the field that staff should periodically attend. Training is important not just to grow and maintain knowledge and skills, but also to credentialize the staff so the rest of the organization comes to understand that applying user experience is much more than just implementing one persons' opinion.
• Work on disseminating more information on what user experience is and how it can help the organization achieve its goals. A good way to do this is to bring in one or more outside speakers to give short talks to a lot of people. It's important that everyone in the organization know what user experience is and how it fits with the goals of the organization.

---

HFI encourages making usability a "socialization" process. Show evidence that usability is "popular". Encourage the bandwagon effect. Institutionalization can only happen when everyone agrees there is no risk.
Solution: Nothing speaks better for a successful future than a successful past. Start with projects small enough to guarantee success. Increment. Grow. Only make promises you can keep. Be nice.

---

• Spend some time researching possible user experience vendors and try them out on a project so you will know who to turn to when your workload expands and you need assistance.
• Spend some time thinking about the best way to get everyone in the organization aware of what user experience is. Talk to your Executive Champion about how to include more groups and departments. Think about what kinds of "PR" you can do so that more people are aware of the user experience initiatives that have been completed or are underway.
  
• You can have user experience groups (product ideation, user-centered design, usability testing) together in one part of the organization, or they can reside in different places, but if they are in separate places in the organization, you need someone to coordinate everyone's activities.
  
• It's common to find in an organization that user experience is piecemeal or that the quality of the work depends on a few star user experience people. It's always nice to have great staff, but if you want user experience to be stable within the organization, then you need to rely on standard processes such as standards, templates, and training. You want to get to the point where the quality of the user experience work does not rely on a few key people.
  
• It's important that programmers and developers, managers and other staff throughout the organization are all aware of user experience. Not everyone has to be a user experience expert or professional, but everyone needs some education and awareness training. The education and training you provide for each group can and should be different, but everyone needs to know what user experience is and what it means for the organization, as well as what their involvement is, and how that fits with what others are doing.
  
• If you want user experience to permeate the organization, then every development project should be using standards and templates.
  
• If you want user experience to exist throughout the organization, then every major development project should be using user-centered design methodologies.
  
• In order for user experience to become part of the culture you will need to integrate your user experience work with the methodologies and processes of the technical/IT group.

The observer effect subdued?

Do you feel this process could help you avoid the bias you might introduce into an interview?

You would not be pointing to any elements of your own design to start the conversation.

Better yet, you will have put any web page of special interest to YOU in a context that lets your PARTICIPANT decide what's interesting.

This is the achievement of the Repertory Grid Technique.

Veronica made these additional observations...

1. Pictures and layout greatly influenced participants. They gave visceral responses like feeling "hungry" or when seeing figs, wanting to "buy figs".
2. Participants needed the probes and stimulation of "laddering" to provide details of interest.
3. Repertory Grid Interviews can help determine specifics of what drives a first impression of a website.

"This in-depth information about important features allows researchers to create benchmarking goals for the first impressions of a home page."

Ah, tell me, just how do you feel about that?

What name or "construct" would you use to label that feeling?

And how does this contrast with asking direct questions – or even administering a Likert questionnaire?

Bon voyage!

Conclusion: loving the madness of it all

We live in time of change. Software development practices started with coding. And for many managers, software still means "coding". However, consumer (and corporate) demand for software that transcends training brings a sea-change in perception of what software must do.

Software must be easy to use.

Coders simply do not have the time or expertise to achieve that goal single-handedly.

The future is clear. Usability will win.

And the present is now clear, as well. Usability is winning. Socialize that fact.

Use the resources given above, as part of your talking points.

Send links. Socialize. Tweet the truth.

Institutionalize us all!

Reader comments