UI Design Newsletter – October, 2011
Special Edition

I'd like to personally give you a report on a very different way of doing user experience (UX) work. It improves your efficiency and will make your UX team an essential part of your organization's valuation. The days when the UX team is first to be laid off are past.

A Serious UX Workstation

Twelve years ago I started working on the question of institutionalizing usability. I asked what would happen if you had a workstation that supported UX work? What if it worked on an enterprise basis? What would be different?

We started putting methods and standards into a repository (Usability Central—Best Practices™). We sold a lot of those. And we had reports of cutting the OVERALL time and cost of development by over 10%. It was a nice step.

Of course we needed to manage project documents. We started using a commercial service that held documents and provided an extranet. It was useful and our clients loved being able to easily get documents. But we needed offline access that handled revisions, that just uploaded the changes and not the whole document. And we wanted to start with standard UX projects, and tag projects as using specific methods. So we built our own "project space."

Then one day I found, within HFI, there were FOUR different groups each building their own "persona builder." They had made progress. But of course a "Persona Builder" makes no sense. Unless you are still in the last millennium you need to design based on ecosystems. We need to understand multiple Users, Scenarios, Environments, Artifacts, and User Needs. So we built an ecosystem modeler.

Oh, and then we realized that the things we design sometimes involve many projects during the design process. And sometimes a single project requires several designs. So we needed a "UX Specification" that was separate.

But all these parts are not really useful until they are pulled together in an integrated enterprise facility. Sure you can build an accounts payable system and a separate vendor file. But any sane organization has an enterprise solution. It's the same with UX. What if all these parts were combined synergistically?

The Dawn of
Object-Oriented UX

We realized that we had something really different. It was like in the 1980s when programmers got serious about object-oriented programming (yeah, I know the idea dates back to the 1950s). Instead of mixing up screen calls, data, and algorithms in a single flat programming file (like a stack of punch cards), they broke out parts that could be reused.

In UX work our "single, flat programming file" analog is usually a slide deck or a word processing document. It works. Everyone applauds. But afterwards it is really hard to reuse stuff because the stuff you need is spread out over dozens of these flat files. Sure your document manager can pull all 30 decks that refer to the "middle market" user. But you have to dig through those decks to consolidate an understanding after picking through all the redundant and irrelevant stuff. It is often easier to just go and re-research the middle market.

But what if a good part of what you did as a UX specialist was to build a shared, enterprise-wide model? What if the objects that you created and refined could be used again and again? An individual practitioner working on UX design can not compete with an enterprise approach. Is the resulting model of the ecosystems, projects, designs, methods, and standards valuable? I think so. It becomes core intellectual property for your organization. The UX team becomes core to the organization.

Marketing teams are essential because they soon hold a powerful model of customer wants. They understand what people are likely to buy. But think of the value of a UX model of customer characteristics, sufficient to guide the actual design of new offerings!

The Problem of Effort

Programmers that create objects must work hard. But they know that each object is leveraged many times, so it is worthwhile.

I remember staying up nights trying to figure out how UX staff might not have to work so hard. Then I realized how we do things. When I am first told I am designing for an insurance underwriter in Johannesburg, I don't ask to be told all about those underwriters. I say, "I've designed for underwriters in New York. How are South African Underwriters different?" This saves time. I might even say, "I also know South African cultural characteristics already." I start with what I know. So in our enterprise approach to UX we made everything work that way. You never build anything from scratch. You copy something close and just tweak it.

Now it's obvious, especially when an organization is new, that there might not be a big library of things that are close to what you need. You might not have a good generic South African. You might not have an Underwriter. So we built a library of generic objects, including user types, methods, environments, and artifacts.

We also realized that sometimes there is not time to pull everything about a user together by hand – even with a good starting point. So we built an automated system where we can send out a survey (we use UserZoom™ as our research tool) and programmatically build a user profile based on the responses. Now it's a snap to get a user profile based on actual data.

The Problem of Linkage

I spent even more nights worrying about how to link up the different UX objects. If you have to link each object to every related object, you won't do much else. But it is IMPORTANT. We realized it needs to be in a relational database. For example, you might need to know…

• What tasks does a doctor do in an x-ray room?
  (Given User and Environment, which Scenarios)
• What high-level design work have we done for high-net worth customers?
  (Given Method, which Users and Projects?)
• If you change the wizard screen standard, which users will be impacted?
  (Given Wizard, which Users?)
• Or from a recent project, given a user (or set of users), which seducible moments are there during their everyday banking?
  (Given User and the seducible moment Need, which Scenarios?)

So how can you link everything without having a full time librarian? We made it easy. Just dropping a small linking stamp into a project links everything automatically (because the project tool scans for the stamp barcode).

But the serious interlinkages were only solved once we sorted out that everything really links through scenarios (patient applied for this process). Once you know you are calibrating an x-ray machine you know where it is (the x-ray room), who else is there, what artifacts are used, etc.

What Is It LIKE?

Working with object-oriented UX is different. It is absolutely a game changer. It takes some time and discipline to create the first objects. Then that gets easier. And the work is way easier. A screener is two clicks. Knowing the scenarios a user completes is one click.

Knowing EVERYTHING in a user's ecosystem is one click!

I've found that synergies pop up as the project work organically builds up a model. This often means you can skip the data gathering (saving maybe 35% of a typical structural project). Or do data gathering, building on previous work and answering interesting questions. I guess this is really the definition of mature UX work. It's not having hundreds of practitioners (although that can be good). It is object-oriented UX design.

Can You Do It?

In a decade we will look back with horror at the days when UX work just created flat papers and slide shows. But now is the time for the more advanced organizations to step up and start that transition. You can do it. And we have that UX workstation in place and ready.

For a year, we have used UX Enterprise™ 5.0 – and now 6.0 – among ourselves and with some of our closest clients. Now, for a few grand to setup, and as little as a grand a month, you can try it too.

Learn More

HFI website

• www.humanfactors.com/tools/UXE.asp

Drop us an email

• hfi@humanfactors.com

Call us

• USA: +1 800 242 4480
• India: +91 22 4017 0400
• Europe: +44 (0)207 290 3430