UX and the Reality Problem

As an independent consultant, I am able to work on a wide variety of projects, collaborating with highly diverse teams.  While I’ve worked with some incredibly talented people, I also see a pattern among UX professionals that is incredibly unfortunate, namely what I call the Reality Problem.  At it’s core, the problem is this:

Most UX Practitioners Never Actually Create Anything Real

By Real, I mean actual working software that you can do something with, that is neither a simulation or a prototype, but is in fact the gosh-darn real deal. When was the last time you actually wrote real working code? If your answer is “not long ago” then I applaud you, but I also lament the fact that you probably are in the minority within the UX discipline.

So why is this a big deal? Well, it is for several reasons…

If you’re not building stuff, you’re removed from reality

What if you were writing a book about gardening but had never actually dug your fingers into the dirt, never actually planted vegetables, never watered and nursed them and kept weeds from suffocating them, never felt the joy of seeing them take root and grow and bear fruit.  How could one possibly write a book about gardening without these real, tactile experiences?  It would obviously be impossible, right?  But designing software is in many ways no different from gardening, and to understand software, to know how to design it and get the most out of it, to have a blooming, thriving crop, as it were, well you’re going to have get your hands dirty.

So am I saying that all UX designers need to become software developers?  Absolutely not.  But what I am saying is that unless you regularly dig around in some code, you’re going to lose touch with the reality you’re designing for.  Additionally, you’re going to lose your empathy for the people you’re designing for.

If you’re not building stuff, you’ll have less empathy for those who do

No, by people I’m not talking about end users.  Yes, empathy for the end user is important, but that’s a completely different issue.  I’m talking about your actual target audience, which is not the end users. (They are the target audience of the product itself.)  The actual target audience of the work that you produce is the developers (and, depending on your team or project, other roles, such as visual designers.)

And believe me, if you’ve personally had to write production grade code, I can guarantee that it will impact how you approach your design solutions.  You will, for example, think twice about throwing in some gratuitously cool feature.  For the person with no coding experience, that little dynamic widget thing they dropped in their wireframe took them maybe all of 30 seconds to add.  In other words, there is a complete disconnect between their work and the reality associated with this feature. And that reality is that 30 seconds of UX work can equal a full day’s work for a developer.  Does that mean we should not innovate and continue pushing the envelope?  Of course not.  It simply means that one should be more pragmatic, and defer to the standard solution in most cases, and then innovate in places where you really can make a strong case for that it is worth the effort.

By simply having more of a general appreciation for what is involved in coding something, you can save yourself and your team so much of the time and headache that tends to go into back and forth of a developer having to explain to the UX Lead that, um, yeah, that thing you got in there is pretty darn complex.  Instead, you might be able to empower your design skills by thinking a bit more like a developer.

If you’re not building stuff, you’ll never understand how developers think

I remember many years ago toiling away at a deck of wireframes for a content management system, only to later discover that my detailed design ideas were largely being ignored by the developers.  Why?  Because after reviewing my wireframes, they had then taken a broader perspective on the problem, and decided to use an off-the-shelf CMS framework.  As it happened, that CMS framework came with a default user interface out of the box. In other words, my approach of focusing on the UI rather than on focusing on the design of the overall system led me to wasting a lot of time.

The developer perspective turned the whole UI design process on its head.  Instead of starting by designing a UI, it here was more effective to leverage an existing UI standard and then shift from a design exercise to a customization exercise of that UI.  While my mindset was fixated on creating a UI from scratch, they were all about reuse.  And why did they never mention this to me, allowing me to create a whole deck of virtually useless wireframes? Well, for the simple reason that I never asked.  If I had taken a developer perspective on my design, my starting point would instead have been to first work with developers to research what available frameworks are out there, and then if we agree on one to use as a starting point, my design exercise is instead transformed into a customization exercise.

Another great example of developer thinking is reflected in test-driven development.  In that model, a piece of code is the user requirement. In other words, instead of writing a traditonal list of text requirements, you instead make the underlying intent of that requirement manifest in the form of code.  In other words, since a well-formed requirement should be unambiguous and testable, why not represent it as an actual piece of code that inherently will be unambiguous and will simultaneously be what performs the test of the requirement that it describes?  This type of thinking can be really really hard for UX folks to understand.  But I think if they were to spend less time doing wireframes and more time actually building stuff, it would suddenly make a lot of sense, and the whole design effort would be better off because of it.

4 thoughts on “UX and the Reality Problem

  1. Damon Herren

    Great post!

    In some organizations, there is definitely a chasm between developers and UX practitioners. Keeping our hands in the code is one way to bridge the gap, but it’s not going to work for everyone. Even with a background in development, I find it difficult to keep up with the latest tools and technology.

    Another solution is to actively involve the developers throughout the design process instead of throwing wireframes over the wall to them. Wireframes explain the what, but often fail to explain the why. Developers will appreciate understanding the why and will feel a stronger sense of ownership in the design. The resulting product may have different widgets than originally envisioned, but the overall product will be better.

    Of course, it is not always practical to involve the developers in the design process. :)

  2. Mark Wagner

    Thanks for the article. This is so true. Our small team process looks like this: marketing strategy is framed up into a tactic or set of tactics with expected outcomes outlined. Entire (small) interactive team sits in a room with paper and whiteboards and spends 3-6 hours (possibly over 2-3 meetings) to flesh out exactly what the experience should be and how it should play out. Developers start building the prototype, creatives start working on the messaging, UX people (interaction designers, IAs) start blowing out the details of the use cases into artifacts. The team meets several times like this as things progress and get finalized. usually there are scrums that address both next steps (project/account mgmt) and obstacles. The meetings are designed to assign tasks to accountable individuals. We just launched to medium size projects for big brands and we were able to keep the whole thing within budget and delivered on very tight deadlines. The whole time we have a working prototype from the beginning that people can react to. It’s hard to tell people how to go about this agile process without demonstrating it, if they’ve never been through it. Basically it involves everyone getting their hands dirty, everyone’s ideas get floor time, egos are checked at the door, and constant constant constant communication.

  3. Anders Post author

    @Damon – yup, actively involving developers is also key, but I think the point I’m making here relates more to the capability of a UX designer to know and understand what actually goes into the wireframe in the first place. In other words, to be able to produce a quality wireframe design (or whatever type of artifact you’re working on), you need to have walked a few miles in a developer’s shoes.

    @Mark – glad you liked the article, and seems like you’ve got some great practices in place with your team!

  4. Rotkapchen

    Absolutely agree with the ‘talking to the developers’ discovery. But try this angle on for size the developers should have never been in a position to make such a decision.

    Consider the commercial building industry. Designs/blueprints are created via an entire architectural process and then a set of specifications (NOT requirements) come out of the process. These specifications are put out for bid among a series of ‘trades’. Developers are the craftsmen of the trades. They should be responding to designs already in place.

    Now, that said, if you take this analogy and apply it to the field of IT, the process by which the architectural designs were completed would include architects (not drafters) from all the primary dimensions of the disciplines of IT: UX, data, process, development, etc. They come together to hash out the possibilities to specify the ‘heuristics’ of the design.

    The problem is that the SDLC that we are thrust into is a cycle that occurs AFTER the architecture cycle. It’s in response to a prior design cycle.

    It’s all backward and mixed up.

Comments are closed.