Fighting Usability, or, Learning to See the Big Picture

There was a recent interview in the L.A. Times with Wes Anderson and some of the crew members that worked on the film The Fantastic Mr. Fox.  The article has been getting a lot of attention because the crew members in charge of making it look so stinkin’ amazing gave some pretty harsh criticism about Anderson’s demands.  Some notable quotes from the article:

“Anderson had no idea that his ignorance of stop-motion…and exacting ideas concerning the film’s look would so exasperate his crew.”

""Honestly? Yeah. He has made our lives miserable," the film’s director of animation, Mark Gustafson, said during a break in shooting.”

“Animation director Gustafson…admitted he found some of Anderson’s directive’s bewildering. "There’s lots of things I lobbied against in this movie," he said.  "He’s pushed it further than I would have been comfortable pushing it," Gustafson continued. "He definitely doesn’t have some of the reservations that I have from working with this stuff for years.”

The whole article wasn’t completely full of hate; I’ve just chosen these particular quotes to illustrate my point.  I get this kind of guff and criticism at work too.  I really don’t know much about code or what it takes to implement certain things, but I do know exactly how I want things to work, look, and feel.  I know what kinds of problems I need to plan for and I know what will be deemed unusable, difficult, or confusing by users.  During a recent discussion about how something should work, one of the developers exclaimed, “We’ve already pushed the limits of the web as far as we can, and now you want this?!” 

My response, of course, was yes. 

The whole team room was against me. 

It was a crappy week. 

However, when they got it done and demoed it for us, everyone was blown away by how great of an add it was and how much of a difference it made.  Including the people who gave me hell for making them do it in the first place.

I know I will probably receive criticism for this post, but the fact of the matter is that sometimes you have to do things that are hard or that you don’t want to do or that frustrate you in order to produce the best product (I certainly do, even though I don’t write code.  Developers aren’t the only ones feeling pressure to complete impossible tasks with ridiculous deadlines). 

Take a look at the visual feast that is The Fantastic Mr. Fox.  For as much detail as the animation has and for as beautiful as everything looks and feels, wouldn’t you agree that it was worth it?  I’m not saying don’t fight back if someone is pushing you for something that is going to break your back or break the bank in time it will take to implement, but certainly weigh the value of the functionality that’s being asked for and figure out if it’s worth it, despite how impossible or daunting it may seem. 

As you develop, try to envision the end product, the big picture, rather than getting mired in the difficulty of the bit you are currently working on.  It might help give you that burst you need to push through the hard times. 

…or just make a voodoo doll of the person making the demands.

8 comments so far

  1. Scott on

    Excellent post, and excellent points. The job is to make software that people will use gladly, not begrudgingly.

    There’s also something to be said here for beginner’s mind. The fact that Anderson wasn’t constrained by a lot of experience-driven bias about stop-motion animation meant that he could bring fresh ideas, and push the envelope. The same is true for you. Lack of years of experience writing code probably helps you envision usability beyond the constraints of knowing what is “hard” to do. You can think outside the box because you were never in the box.

    Keep em comin

  2. G Valentino on

    Ditto to Scott.

    I used to write code, web apps, some desktop apps (not great ones) before I went into analysis, and the fearless leader of my company said after reading one of my first stories that the best thing I could do was forget what it was like to write code. Now, some of the ways I structure my stories reflect a coding past (like making sure that common elements are in a common place etc) but for the most part I try not to think of things like table relations, objects etc.

    And I think there will always be some developer pushback, same as there is analyst pushback when it comes to changing the reqs. As I mentioned in a comment to an earlier post, we’re using a “preliminary technical estimate” model for the analysis. I’m sure after the next iteration, we’ll have a better idea how well that works.

    Can’t wait to see Fox. I’ve been wanting an Anderson stop-motion since Zissou.

  3. Brett on

    Developers love to do things that are hard. As long as the boss gives us plenty of time and materials to get it done. But when we get pressed for time (which is nearly always), hard is a four-letter word.

  4. Scott on


    I’d extend and modify your comment to say developers love to do things that are hard and *interesting*. Most of the time, the stuff that makes a UI usable and is hard is less interesting to implement than people like

  5. brian on

    Understanding, that end user experience is the value in the final product, and undoubtedly this is what will leave the biggest impression on the user… I don’t believe that being devoid of technological aspects of the application is the best way about it. Something strikes me bad when there’s this vision, mostly, in the development team aswell, that programmers are just a black box you beat with a stick until you get the app you want. If you can stand up in front of me, and say that is your impression, I will tell you that either you are wrong by making the statement, or I am not employed in the position that I was hired for. I am not a programmer, I am a developer. There is a difference.

    However, in regards to pushing the limits of the web, perhaps a better understanding of the web would shed some light on that statement. As I’m sure it was not out of complete ignorance, nor just complaining that the feature had to be put in.

    A lack of understanding of technology, for example, could result in a business analyst looking for something like, showing a pdf in an iframe. This seems usable. It worked in firefox, and that’s what everyone should just use right? (they would in my perfect world). Unfortunately, this was the specification, but, it was also the specification to extremely limit browser support. afaik, iframe is not part of html 4.01 strict. This would cause developers to use a transitional doctype, and put the browser in quirks mode. This can cause your application to render inconsistently accross different browsers. Web developers spat and laughed on the tech requirements splash page years ago.

    Although, HTTP is stateless in nature, we can use asynchronous requests to update portions of a page; however, the use of javascript is also a technical requirement for the page. Understanding that rich internet applications must depend on javascript to get the “application” sense, it’s something you’ve gotta tell your users. Also, javascript performs differently cross browser. I’ve seen a lot of the usability flag being waved around in the name of user friendliness, and “we’re doing this for the user, so make it happen”. Ironically, accessibility, somehow falls by the wayside of usability. Additionally, javascript can be turned off, and or manipulated. This can create hard to find security holes in the application. Not to say javascript should not be introduced into web applications, but a more managed approach, balanced with user experience might have been the better way to go about this.

    Also, I’ve run into a lot of context overload. I guess as a developer I don’t know how to appreciate or develop usable software. But, typically, when I’m editing a friends list on a social networking site, I do not have every option one can think of in one small area. I do not consider that unusable. Friend list management on something like facebook isn’t this scenario: organize your friends, add new ones, edit connection details, remove friend, suggest friend all in one lightboxed form that is 600x400px.

    The kind of experience that is created here is a very specific application flow from one step to the next. User allies in their web browser are not functional, such as back, bookmarks, or relevant history. Should a user perform an action outside of an expected flow, it can orphan records in the database, it can also cause problems in sessions storage as the user did not arrive at the action that cleans that bit out of the session. The best route I’ve seen for this is to update hidden fields in the dom, and use those as temporary data stores. This can also be manipulated by the user, and cause security holes in the application, or a very specific security model would have to be in place to predict unexpected user actions.

    I honestly doubt that stories I have come across give a sense that it might seem hard or challenging. But, I can say that it might be hard for me to do something, knowing the impact it has on the software, and the requirements for the user. Also, what is usability if the application is using the user, instead of the user using the application. I see no user friendliness in accidental mistakes as small as the back button (if your cursor is not focused in a field, and you press the backspace, there goes four pages of wizarding. I don’t see how that’s pure usability).

    I am currently working in an application where there is not a hyperlink that is actually a straightforward link as opposed to a client side browser redirect or an ajax call. (all of which cripple history and back button) This is paraded as usability, where I see it as a potential issue for the client using a web application as they would any other.

    I’m not sure you would find support for many of these design techniques and user experiences in any proper web development shop. This is not to say it should always be able to render in a screen reader, or text browsers. But, broadening web browser support is definitely something to keep in thought as you are developing a web application. Web development as far as I know is to be dependent on making the application as accessible as possible. Not driving up the technical requirements to a very well defined system that would closely resemble solely the dev teams suite of browsers, os, and tools. I do not see that as usability.

  6. James on

    Developers also have ideas and input into design, they are not Programmers. They also have to balance all of the ideas with security and performance concerns among other things and time constraints if an idea is time-consuming to implement.

    In a good development team with all the developers from junior to lead, testers, and the business analyst there will hopefully be a lot of good ideas for the project. The developers do their best to make sure as many of the best ones get in as possible.

    When a developer is made to feel like they have no say in design and functionality, despite having years of practical experience, professional experience, and/or education they are going to get frustrated, and eventually might give up and just program whatever story comes along. In either case you lose quality.

    No one has a monopoly on the good ideas and no one is above having a bad one now and then.

  7. […] wrote a post on a similar note a while ago, and I got a lot of flack for it.  I hope this post makes my […]

  8. ultram on

    It’s hard to come by educated people on this subject, however,
    you sound like you know what you’re talking about! Thanks

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: