Mr. X and Dustin Curtis

Via a Tweet from @uxforward, I encountered Dustin Curtis's admonishment of American Airlines, the reply from a UX architect at AA.com (and Dustin's response to it).

I love the internet.

Anyway, I found this exchange to be fascinating. The main thing that resonated with me was Mr. X's statement:

But—and I guess here’s the thing I most wanted to get across—simply doing a home page redesign is a piece of cake. You want a redesign? I’ve got six of them in my archives. It only takes a few hours to put together a really good-looking one, as you demonstrated in your post. But doing the design isn’t the hard part, and I think that’s what a lot of outsiders don’t really get, probably because many of them actually do belong to small, just-get-it-done organizations. But those of us who work in enterprise-level situations realize the momentum even a simple redesign must overcome, and not many, I’ll bet, are jumping on this same bandwagon. They know what it’s like.

Amen!

This reminds me of the book review I did on Robert Hoekman's "designing the obvious". In the review, I said, "The only major problem I had with the book, and it's not all that major, is that it was written with an assumption that bad design happens out of ignorance for many of the principles he is espousing. That people are not doing things the right way because they don't know the difference between the right way and the wrong way. Clearly, this is sometimes true, but I think it's the exception to the rule (at least it is the exception when there are professional usability people involved in the project... and the audience for the book seems to be professional usability people)."

To net it out -- coming up with a good design is the EASIEST part of creating a well-designed product. Hell, it's almost trivial.

Dustin thinks this is a cop-out. In a sense he's right - it's a cop-out from the perspective of American Airlines as a company, but it's not a cop-out from the perspective of Mr. X. American Airlines, like any large corporation, has to figure out how to deliver well-designed products in spite of the difficulties that come from being mammoth. But Mr. X wasn't excusing AA from responsibility and he wasn't saying that nothing could be done. He was just pointing out (far more politely than I would have) that's Dustin's belief that the problem with AA.com was that no one could tell good design from bad design was hopelessly naive.

Of course, Dustin's argument that the problem must be that AA's CEO lacks "taste" doesn't dispel the naivete charge. Dustin's heart is in the right place, but I think he really doesn't understand how large enterprises work.

UX Roadblock #17: Development tools and frameworks

In every software release, there are always resource constraints. It's an immutable fact of life, like the sun rising in the east or your toast falling butter side down. There's not a lot of value in complaining about it... and pretending that your work should be done without regard to resource constraints or ship dates will lower your credibility.

However, even if we accept that resource constraints are a fact of life, it still can be the case that these constraints are inappropriately impacting the user experience. In other words, resource constraints are an issue for everyone in every discipline, but sometimes the impact on one area is out of whack with what other areas are facing. One way in which this can happen to user experience is via bad development tooling and frameworks.

Development tools and frameworks are intended to make developers more productive. When done poorly, they can create a situation where developers are more productive if they follow a single path, but any deviation from that path results in a huge development effort. And deviating from that path is often requested by the UX team. This can result in mind-boggling conversations like, "Sorry, I can't change the label on that button... the framework is giving me the label, and I would need to custom code the entire page to change it." The trick is to recognize when a developer is feeding you a line of crap to avoid extra work versus when there really is a tools/framework issue. Or both!

As an aside, one area where I've repeatedly seen this issue is in the area of product installation tooling. These try to make things easier by giving the developers a bunch of common install functions for free. But it's often an all or nothing proposition... you either use the common function EXACTLY or you have to start from scratch. So there's a resource cliff. A minor design change creates a huge impact on the development sizing. So as a designer you get stuck with accepting a bunch of minor irritating behaviors because none of them individually are worth throwing out the free behavior.

As with most roadblocks, we UXers often have to live with them rather than remove them. Removing the roadblock in this case obviously means choosing new tools or creating better frameworks. Sounds good, and worth fighting for, but that doesn't happen overnight. In the meantime, what can we do to detour around the roadblock? Here's my advice:

1. Learn everything you can about the tools and framework so that you know exactly when you are designing something that will force extra effort. Don't rely on the developers to tell you.
   
2. Only design "outside the framework" when it matters. This builds on #1. If you ignore the framework when doing the design, you'll run into situations where you are deviating from the framework randomly, out of ignorance, which causes unnecessary battles with development or forces developers to spend their time on things you don't really care about. When you deviate from the framework, make it count.
3. Build an expectation into the development sizing effort that deviating from the framework is normal. This builds on #1 and #2 - they give you credibility so developers know that you aren't being a hardass for no reason. You want to avoid a situation where any deviation from the framework is considered "extra" work that needs to be separately contained. Assume there will be some deviation upfront, and size accordingly. This is also the key to removing the roadblock altogether - the cost of sticking to the framework needs to be exposed via the sizings.

UX Roadblock #48: Sexy Requirements

There are a thousand different ways to manage requirements and plan a release. One of the all too common methods is to make a list of the biggest, most important requirements and rank them from top to bottom based on "customer need". Of course, "customer need" can mean anything from "an executive already promised this to a customer" to "marketing thinks this feature will enable us to get into a new market". If you've been on a team that used this method, you know what happens... people learn that the best way to get your favorite requirement into the product is to make it as big and sexy as possible. Because once you have the ranked list, sizings are done and once the resources run out you've got your list of in-plan requirements. If your requirement isn't near the top, now matter how easy it is to do or how great the ROI is, it won't make it in.

This is a bad method for lots of reasons, but it particularly hurts the user experience. First, the overall user experience is made up of a ton of small interactions, and often the best way to make improvements is to fix a lot of small issues rather than add some groovy new "user experience feature" while leaving the small issues alone. Those small issues add up quickly. But comparing any of the small fixes to one of the big sexy requirements makes the small fix look optional.

Second, this type of process encourages a "feature-centric" view of release planning. The discussion naturally becomes focused on which of two features is the most important... and tends to avoid the discussion of whether either feature is the best way to spend those resources. Making the existing features better gets lost in the mix.

If you are stuck in this situation, you might not have the ability to force a wholesale change to the process (which is what is ultimately needed). If that's the case, here's some pragmatic advice on how to get around this particular roadblock (based on my own experiences):

1. Create a big sexy requirement that is a collection of UX improvements and try to tie the individual improvements into a single theme that will sound good to release management, like "Decrease customer time-to-value through out-of-box-experience improvements". Of course, you'll know that this is really just a bunch of little improvements, but by combining them together by theme you'll be able to better compete against the new feature requirements.
   
2. Work with release management (and product management) to create "buckets" of resources that are dedicated to particular release objectives, then prioritize within the buckets. And, of course, make sure one of the buckets is dedicated to user experience. This is easier than it sounds because (almost) no one thinks user experience is unimportant, and at a theoretical level it's easy to convince folks that some percentage of effort in a release should go towards improving the user experience... the problems arrive when those well-meaning people are forced to choose between a new feature that some customers genuinely want and improving the user experience. By creating separate buckets, it removes that forced choice.
   
3. Partner with the folks who are working on one of the big sexy new features that is likely to make it into plan and persuade them that there are a number of user experience improvements that ought to be tied to the requirement. One reason this technique can be so successful is that adding user experience items to the new feature can make it even more sexy, so the people pushing the new feature are motivated to work with you. The downside to this is that unlike the first two techniques, tying the UX improvements to a new feature constrains your choice of which UX improvements to tackle. You have to pick things that relate to the new feature, however loosely. Of course, if your choice is between getting nothing done versus getting your second or third choice done, it's still an easy decision.

None of these actually removes the roadblock, they just help you get around it.