September 2008 Archives
"...which is what makes their sales figures so ironic," added J.
The book Head First Design Patterns defines a design pattern with this simple statement: "A pattern is a solution to a problem in a context." The usability study that kicked off the redesign project framed the site's problems in design patterns like "Understanding", "Organization", and "Recognizability". After identifying a problem the test user encountered, they would match it to an established pattern, then use that pattern's guidelines to suggest a solution for the particular application. In this case, the user's difficulty completing a task defined the problem and the activity during which this surfaced was the context.
It occurred to me that if the problem or the context was not so clearly defined or delineated it would be possible to get one or both of these wrong. If you did, your solution would be wrong as well. Looking at the other half of the equation, you could also choose the wrong pattern for your solution. In usability we work from a list of clearly defined and well-tested patterns. In life we work from patterns that aren't as clearly codified. Sometimes these patterns are management principles and sometimes they are de facto patterns created by repeating an action or decision until it feels familiar.
What if some of these de facto patterns were actually inverse patterns or anti-patterns? That is, instead of being solutions they were recipes for disaster? If that were the case maybe disaster could be avoided. Perhaps it depends on correctly identifying all three pieces of the pattern equation. That is, clearly and correctly understanding the problem and the context, then applying a proven pattern.
If two groups of hikers are lost in the woods and one group decides to hunker down and wait for a rescue and the other decides to look for a path out of the woods, which group will have the best chance of survival? They both have the same problem: they are lost in the woods. Here's where the context is important because it helps define the problem. For instance, "We're lost in the woods with plenty of food but no shelter and there's a snowstorm coming over that mountain" is a different context from "We have tents and sleeping bags, but no food and we're at least a day's walk from the park entrance." In the first context the best decision might be to find shelter and wait it out. In the second context you can protect yourself on the journey, but you don't have enough food to risk being snowed in for a week.
In the specific case of our redesign project the Europeans' problem was "How can we quickly stop the downward trend of our online sales?" Their context was a website we'd built for them that they didn't believe fit the needs of their European market. Their solution was to redesign the checkout process as quickly as possible, without further input from us, and push it through in time for the earliest release possible. From our side the context was "When the Europeans give us a development project the funds they allocate to our department improve our bottom line and make the managers look good. So our problem was "How can we employ our team to give the European's what they're asking for?" The solution to that problem was "Find a way to implement their design proposal." Seen that way it all makes sense. Both sides are effectively solving their problems. It should be a win-win situation. So why does it smell so bad?
The answer to that question, I think, is in the solutions. To distill both of the above solutions to their simplest and harshest terms, they look like this. For the Europeans the solution becomes "Throw together a new checkout process in two days and launch it with no user acceptance testing and hope it works." For us it is "Develop a web application interface using a rough graphical sketch as our sole architectural document and hope it works."
I'm still on the meeting roster. Gee… If David is going to be implementing this he really ought to be invited to the meetings at some point…
This meeting is about feasibility. Forget for a moment that we don't have a working design. Our site flow diagram wasn't made in Visio—it's just snaps of the cut-and-paste comps with arrows going between them. We don't have wireframes and the comps are still just "rough drafts", so we're not exactly sure what the pages are going to look like or what they're going to do. The term "ajax" has been bandied about, but no one is quite sure what that involves. We'll sort that out later. For now we're just asking in a conceptual way if "this" can be done.
What is "this"? It's a generalized flow. Can we make this sort of server call? Can we send a user here instead of there? The back-end guys have a few concerns, but in principle there is nothing that can't be done. We don't need to concern ourselves about technical architecture or how convoluted flows might affect our code base. We don't have a TA and we never will. Theoretically, it's all good.
I found myself thinking about war crimes. Tribunals convene and, outraged, they ask, "How could this have happened? When did you let go of all decency and commit this hideous crime?" The answer is an ashamed admission that it happened gradually. One small thing led to another small thing. There was no plan to do what happened. It just… happened.
"Venkat" said the server could be made to do it that way. "Matt" said he'd seen cases where that sort of call could be made to the database. We were talking "technical" so interface didn't matter. IA didn't matter—not at this stage. We were just talking feasibility. Is it feasible? Yes.
But now that the back end guys have let it pass without a red flag it has firmly ensconced itself in the realm of the possible. It is now viable, i.e. It's alive!
When I came in on Monday morning I had a 10 am meeting with Randy, Edmund and Erica. I thought it was going to be brief account of how the Europeans took the news that we weren't going to be using their half-baked comps as a basis for global e-commerce web development. Imagine my surprise when Edmund and Randy began the meeting with a discussion of scheduling for the project.
Did I fall into a parallel universe? What had happened to "no"? Instead I heard comments like, "There nothing here that we couldn't do" and "It just needs a little tweaking." Edmund diagrammed the new flow on the white board and to me it looked like a ball of yarn, but Randy said, "I'll diagram that in Visio and get it out to them by the end of the day."
I reminded Edmund that architecture is an integrated framework. It all has to work together and if one part of it is flawed it affects the entire design. Everything has to make sense before you begin or you risk going down a dead end.
I also pointed out that it was lunacy to think that in 2008 web development could be done by executives who had no knowledge of usability or information architecture. His answer was, "We'll just have to agree to disagree." (Since he's my boss's boss that translates to "Shut up.") A few minutes later when Randy asked him if he thought we could make this thing work he said, "I've been in e-commerce for ten years—I feel comfortable designing the new site for them."
I took one last shot. "What are we going to do about resources? Am I still full time on our B2B site?"
"Yes," he replied. "We'll get "David" to handle this."
David was hired three weeks ago. He's number two in our global e-commerce presentation layer development group...of two. So now I'm just a bystander. I was that annoying character in the movie who kept saying stuff like, "If we stay here we'll die! We have to get to that town we flew over and get help!" and who finally abandons the group to find salvation on his own instead of waiting for rescue. Anyway, maybe I'm being too dramatic, but I think there's a good chance I won't get eaten—at least not in the first round. But just in case, I added up all my time off. I might need an escape route.
I told him I thought the problem was that Europe was, essentially, a small pond. Even though they make only a fraction of the revenue we do they have short chains of command and they're headed by a V.P.-level executive. If one of their regional managers doesn't like what we're doing they push back, but they go directly to their V.P. and he pushes back on us at our director level and rams it down the chain of command in our IT department. So they effectively own the global web dev. team. For us to trump them we have to climb very, very high up our chain of command to find a V.P. of equal status and power, and those guys don't concern themselves with such low-level issues.
Edmund agreed saying, "If I have to call my V.P. it means that I've failed to do my job." He thanked me for my insight and assured me that this time it was going to be different. We had to say "no" and we would say "no". He asked me to prepare a brief PowerPoint outlining the reasons we couldn't go ahead with the European proposal (for ammunition), which I submitted that Friday morning. I went home at the end of the day thinking that it was all going to be okay after all. My bosses were finally going to push back, we wouldn't trash our code trying to rebuild the site for the Europeans and we'd find a way to roll their usability update into the one we were planning for Q1 of next year. What a relief!
I've always been fascinated with the process whereby groups reach a decision. I've seen the collective brain power of the group discover amazingly innovative solutions to complex problems. Most of the time group decisions tend to be compromises—proposals that don't give anyone a big win, but cause no harm. Sometimes group decisions go horribly wrong and people end up eating each other on a desolate Andean mountaintop. That's the process I find fascinating. Not the cannibalism, but the chain of mistakes that, if taken individually, don't seem important but collectively add up to disaster. How did a bunch of very smart people screw up so profoundly? What were the warning signs that went unheeded? Where was the critical juncture when all could have been saved if only…?
I have an opportunity to explore that process now and to chronicle it in this series. My goal is to get it all down in writing while it is still fresh. In fact, it's taking place at this very moment. So I don't know, in fact, that I am witnessing a disaster in the making. I'm just going with my gut.
Part 1: The Rush Job
We just finished the final European launch that included bug fixes and functionality enhancements. That should have marked the end of the project. But no sooner was it finished than Europe went on the offensive. They hired a usability company to do a survey of the site. It was a modest effort, but it was sound and professional and I agreed with their findings.
As soon as the European management team received this the head honchos formed a task group to address the problems it had uncovered. That group consisted of about half a dozen executives and someone with a creative background (marketing and print advertising, I think). She was the designated artist for the project. A few members of our team were invited, but the meeting started at 3 am on a Sunday morning, so we passed.
After two days of fierce brainstorming the task force presented us with a set of graphical mockups ("comps") and told us, "This is what we want the site to look like." The comps were jpegs they had made by taking screen captures of the existing HTML pages and rearranging them by cut-and-paste. They featured major usability and information architecture flaws, such as a single radio button: Once selected it could never be un-selected. If they only needed 194px for a column width, then that's all it got. So three side-by-side columns were 194 px, 288px, and 219px wide. I'm not a math genius, but I ran these numbers through my calculator several times and I couldn't find a mathematical basis for those proportions. It was suggested that their registration forms were too long and should be simplified. Their answer? Chop them in half and make two columns.
They gave us the sort of comps you would expect to get from a "web design team" that did not contain a single member with usability, information architecture or web design experience. The sad part is they wanted to know how soon we could start development because they wanted them for the next release, which was less than a month away. I took one look at the comps and announced to my team that there was no way we could develop from these documents; they were fatally flawed. The director ("Randy") and his boss, the senior director ("Edmund") both nodded their agreement. We had to find a way to break it to the Europeans that this proposal of theirs just wasn't going to fly.
I prepared an elaborate document tactfully presenting the steps usually taken in a redesign project. It started with a comprehensive competitive analysis and included examples of real-world web redesign deliverables, such as flow diagrams and wireframes. The Europeans thanked me for going to all that trouble, but assured me that the comps they had sent included all of that already.
"What about the wirerames?" I asked.
"Oh, we did those on the white board at the very start of the project. Of course we erased them, but the gist of them is included in what we sent you."
"But what you sent me is crap," I said (in more tactful terms).
"Those are just rough drafts to give you the idea of what we want."
"Okay," I said, "but you told us to start developing from them."
"Well, that's the general idea of what we want."
