Back to blog

Shipping an Empty Box – UX in the Enterprise

Here is the script of the presentation I gave last night at Refresh Events in Toronto.

In 1980 IBM executives met to determine how they would respond to the very rapid growth in the personal computer market. As a late comer to the market, they asked how long it would take for them to bring a PC to market. After much research they determined that using their normal processes it would take them 4 years for get a PC to market. In fact, their internal workflow and processes were so complex and bureaucratic that it would take them 9 weeks just to ship an empty box.

The prospect of not being able to get a PC to market for several years was just unacceptable. So IBM chose to take a small group of engineers operating outside of IBM’s processes to develop the first PC. At this point this story goes on to have a bunch of implications, it branches off into the creation of Microsoft, the creation of Compaq and the other clone makers and generally is the start of the PC’s rise to dominance in the 1980s.

But what I want to talk about today is the empty box problem. What I hope to convince you of today is that the problem of the empty box for IBM is the same problem that enterprises face when trying to deliver great user experiences. The modern process of creating great UX sits counter to the modern operating processes of large enterprises.

So why did it take IBM 9 weeks to ship an empty box? Quite simply it is a matter of physics. The mass of IBM was so large that the energy required to move anything through it equaled at minimum 9 weeks.

Large enterprise clients have similar problems with doing anything. Just to wrap their hands around a problem requires the problem to be of a certain size.

Let me give you an example of this in the context of a UX dilemma. A recent project of ours had designs that required the dynamic resizing of images. The same image would appear in various sizes throughout the site.

While everyone agreed that the new design was a better UX, they lacked the technology to do this. No problem we said, modern image libraries with a few lines of PHP could solve this problem. Well this client had committed to using JSP.

Still not a problem there was freely available JSP out there to do this very basic resizing task. Well this created some problems for them. What would the performance issues be for resizing all these images? Would it create security holes? Would it compromise other functions? Did they really want to deploy custom code, maybe they should examine an image server software?

Suddenly what was a pretty straightforward problem to us, was an extremely large IT decision. One that would require audits of existing technology. Something simple like dynamic resizing an image didn’t exist.

The problem was too small. A simple solution just couldn’t work because it was, well too simple.

In another client of ours, to make a change more substantive than a text change to body copy requires a UAT process that takes 6 weeks, minimum. That is their empty box problem.

“We have learned that trying to be highly predictive as to the success of designs at the start of a project is very difficult, bordering on impossible.”

Now here is where the empty box comes into conflict with user experience design. Modern UX design is favoring a model of constant improvement. We have learned that trying to be highly predictive as to the success of designs at the start of a project is very difficult, bordering on impossible.

The best UX design seems to be coming from designers implementing a release early, release often mind set. People like Jason Fried at 37Signals preach a sermon of simplicity and getting real. Build it, release it, watch it, refine.

It is a good methodology I think it yields over time a good UX. It favors responsiveness and nimbleness… and for most enterprises incredibly difficult to do.

The modern notions of UX design run counter to the processes and legacies of the enterprise and it is one of the major reasons that it is so difficult for large companies to deliver good UX.

A recent home page redesign project we worked on really highlighted the delta between modern UX processes and Enterprise’s challenges with it.

Our client needed to refresh their home page. Like many clients they wanted us, inside of this project, to design not only what was to go live first but also design for a handful of future releases of the home page. Each successive release had fuzzier and fuzzier requirements. Some of which depended on us knowing how users were reacting to the previous version.

I suggested that we take an approach where over the period of months we incrementally redesign the home page. Releasing features every few weeks. I figured we could design and have them deploy a new home page in about 8 weeks. An already long time but about the shortest they could do anything. They would then create a new project that would release an upgrade 3-4 weeks later. And then another refresh a few weeks after that.

Our client agreed and then immediately began adding the scope back that we had removed with a continual improvement model.

At the same time new pages somewhat unrelated to the project were being added to our work load.

Now it wasn’t scope creep in the sense that home page was getting more and more features but rather other pages were suddenly being attached to this project. It was like a Bill going through congress and receiving ear marks as it goes through the process. I kept pushing back trying to de-scope it so we could focus on the challenge of the home page redesign.

I couldn’t understand why this client wanted to keep adding scope (that they were prepared to pay for) and making a simple easy project into a complicated project. What I finally understood is another aspect of the empty box problem, and it deals with resource allocation.

Companies have demands for resources. When I say resources I mean not only the people but also capital resources. In this economy demand will always outstrip supply.

Determining how resources will be allocated to one project over another is different in every company but essentially it requires managers to assemble teams for the duration of the project. After that project is completed those resources will be allocated elsewhere in the enterprise.

Companies tend to like to allocate resources for longer periods of time. It’s just easier to say these 30 people are unavailable for the next 6 months rather than allocating resources every two weeks.

Project teams have a team leader, PMs, day to day contacts and then a host of business analysts technical people, legal etc… Once you are assembling a team you might as well optimize the amount of work they are doing while they are allocated to you. Because, god knows when you will get them again.

So what this client was doing was increasing scope just to get the project done. Just doing a home page was too small a project to wrestle the resources she would have needed. So they made the project larger. The paradox of this is that now the team was dealing with solving 5 or 6 related but unique UX problems. Since we had expanded the scope of the project, more departments were being affected by the designs and as a result we needed to get their approvals. Now we were managing consensus which has its own toll on UX.

Our attempt to release early release often was just impossible to do inside the processes of this client, even though it was widely agreed it would have gotten them to market quicker and yield better results. Small projects often mean small returns in large companies. They just like things to be bigger.

The financial allocation model doesn’t help the situation. Companies like to allocate budget through a CapEx process. Typically this means that managers go in front of C level execs with their projects and request funds to develop those projects. It would be insane to go and request anything less than several hundreds of thousands of dollars or even millions. This tends to bias towards large multi-year projects where costs can be written down over several years.

In fact, in many companies the code for projects will come as a capital expense, no different than if they bought a forklift or a printing press. It gets accounted for as an asset of the business. But the design is often considered a operating expense. It’s treated as marketing which has very short term value once it is released.

If I were to describe modern UX design process one where we were constantly tweaking the designs for continual improvement, they would probably set up an operational budget rather than a CapEx budget. But at the same time they would want aspects of the project to exist as an asset on their books so it would not be a straight loss. Now you are back to their CapEx allocation process… we move between scaling up and scaling down.

“in some clients things we designed over a year ago are just getting to market. In many ways the design is obsolete as it hits the market.”

If you scale up a project where the design process alone takes 90 days, then building takes 180 days and then UAT another 30 to 60 days a project that is designed say between Jan and Feb goes to market in in Sept or October. That is being generous, in some clients things we designed over a year ago are just getting to market. In many ways the design is obsolete as it hits the market.

OK, so those are all challenges of scale and we haven’t even discussed the more traditional challenges of delivering great UX.

If you ask most designers what makes for successful client projects they will tell you a senior decision maker. For years we as an industry have sought to gain C-level access.

The reasons for this are not only budget and to have interactive projects taken seriously but also because when someone very senior is interested in the project decisions get made but I would argue that the real benefit is that having a senior person involved is that often fewer compromises get made in the design.

The further down the ladder you are, the more the job becomes about consensus building. In a large enterprise, managers are often valued for their ability to gain consensus among multiple disparate stakeholders with opposing interests.

We’ve all experienced watching a great UX slowly erode in the name of compromise.

The existence of what I call a “design dictator”. A singular designer with a distinctive voice who makes absolute and final decisions about what the UX should be. This role rarely, if ever exists inside the enterprise.

Hired consultants lack the authority to impose autocratic design decisions on clients, while corporate design directors are often just brand cops managing the operations of design services rather than making absolute product decisions.

The majority of UX decisions are left to “The Team”. The team needs to come to consensus and consensus means compromise.

We in the UX community have tried to manage this type of erosion of UX with tools like user testing and personas. While these tools are valuable for working out ideas their real value comes in their ability to gather consensus in the enterprise.

The fact is that a small team of designers and programmers with the authority to define the UX of a product will accomplish more in less time with less money than a typical dev team.

The classic iPod/iTunes example is primarily due to the vision of Tony Fadell. A team was isolated for its development from the rest of the company.

The original IBM PC was ultimately built by a team of 12 operating outside the confines of the existing structures in Armonk or White Plains. It was designed in Boca Raton Florida.

So I’ve painted a pretty bleak picture about why it is very difficult and maybe impossible to do truly great UX inside the enterprise. So how do we fix it?

The quick answer is that if you really want to do great UX in the enterprise, you probably need to identify and isolate a rogue team. When we’ve been able to get the client to do that, it really improves the work.

If you can work with the COO or CFO to try to understand the financial allocation process and the figure out how to explain to them what you need, they may be able to open new processes for them. One client story, a client was in their CapEx process and was asking for dollars for a Web project.

The CFO asked “didn’t I just fund a Web project, when are we going to stop funding the Web?” Luckily the CEO said “Never” before our client could answer. But the CFO, was used to funding IT. Big spend, long time to implement, depreciate it.

They had never considered that there was an alternative. We sometimes take for granted that the way we think is the way others think. As soon as the CEO said “never” the CFO was forced to think about funding the Web entirely differently. “Oh, it goes in this column”.

So changes in thinking like this are evolutionary but to wait for an entire generation of CFOs and COOs to die is a little too slow for my liking. There are a few things are happening in the enterprise that will begin to accelerate change.

Firstly, business timeframes and windows are collapsing at a rapid rate. Business understand that the pace of change has accelerated and that time frames of the past are no longer acceptable. Responsiveness and nimbleness are desirable attributes in the business world. As these business imperatives come to bear on the market, business will face increasing pressure to retool processes to get products to market faster and more frequently.

Second, the commoditization of technology continues. Businesses are able to offer UX features by utilizing Web services for low cost or free. You need a picture gallery or video gallery? You no longer need to build from scratch. Widgets, APIs, hosted solutions all lower the weight of delivering great UX.

I’ve seen quality increase while, time to market and cost drop significantly when the enterprise uses hosted solutions.

“You cannot overcome a dysfunctional organization with wireframes.”

Finally, I think this recession is going to benefit us. As spending contracts, the desire for smaller projects that show value quicker will become more palatable than large CapEx projects. This descoping of projects can benefit the overall quality.

I know I haven’t provided specific tools or tips and tricks to help solve some of these problems but I think that as an industry we spend an inordinate amount of time debating, what is the role of an IA or are personas worth it instead of looking at the context within which great work can occur. In my experience the best documents or skills will not overcome fundamental organizational barriers. You cannot overcome a dysfunctional organization with wireframes. Not going to happen.

Hopefully the story of the empty box will help you identify some of those barriers and inspire you to find new solutions to breaking them down.

Jon Lax More posts by Jon Lax