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.

Taking the UX Book Club to the edge

This last Thursday, we had the first NYC edition of the UX Book Club.  I attend a lot of UX-related events, but this one had a palpable energy and excitement that I haven’t seen in some time.  At the beginning of the event, some of us offered mini-reviews of our book choice, Bill Buxton’s Sketching the User Experience.  Peter March gave such an impassioned review, I kept expecting him to whip out a bible and start waving it.

And that sort of set the tone for the rest of the event: high-energy, engaged conversation, a fertile middle ground between events where there is a single speaker with everyone else semi-passively engaged, and free-for-all cocktail hours, which are fun and great for networking, but lighter on substance.

Now, with a couple days hindsight, I have both great hopes for the potential for where this budding movement might take us, but also a creeping fear, concern, trepidation, whatever, that we will only read the books we’re already talking about, only the books written by people in our midst, only the books matching a search for “User Experience.”  Our reading choice for the event, Sketching UX, is a great book, dare I say an important book in the UX canon. We should of course keep reading books like this, book club or no book club.

But if we only read Books Written By People Like Us, I fear the UX Book Clubs will become navel-gazing, inward-looking, gatherings, where we mostly are drawing on ideas coming from within our practice. One way to prevent that from happening is to mix up our book choices a bit, and also include voices at the edge (or outside) of our practice, which I think would enrich our practice by looking at it from the outside in.

These are two books I think exemplify that edge, that are written by authors at the edges or outside our practice, and books I would strongly recommend as a reading choice for the UX Book Club.

Drawing on the Right Side of the Brain, by Betty Edwards

Drawing on the Right Side of the Brain, by Betty Edwards Though it will teach you how to draw, this is less a book about drawing, and more a book about seeing and thinking about drawing and illustration.  Too often, the focus when talking about sketching and wireframes is on the what (nomenclature, hierarchy, flow, etc.), which of course is important.

But just as important is the how.  A brilliant design concept presented by way of a crappy-looking sketch or wireframe is likely to be far less persuasive than one produced by a skilled illustrator.  And I’m not talking about whether or not an early idea looks sketch-like to invite feedback. Even that, attention to fidelity, is part of the illustrator’s craft.

And that is what Edwards teaches in this fantastic work, not only how to draw, which is important, but how to make drawing something you just do without thinking, like riding a bike. In fact, I think this book should be required reading as part of the core curriculum in an Interaction Design program.

Crystal Clear, by Alistair Cockburn

Crystal Clear: A Human-Powered Methodology for Small Teams Moving to the opposite edge of our practice, this is a book by one of the leading progressive thinkers in agile software development, and one of the original signatories of the Agile Manifesto.   In my opinion, it is one of the best books on the agile and iterative development methodology.

But more importantly, from the vantage point of a UX Book Club choice, it takes the developer’s vantage point: a crisp, unvarnished, and unforgiving take on what it means to design something that ultimately will need to take the form of ones and zeroes.  (Getting back on my what-should-be-in-a-ixd-curriculum-bandwagon, this is also a book that I think should be part of such a curriculum, but as part of an advanced course.)

Let’s not forget who are the ultimate users of our work.  After business stakeholders have hemmed and hawed about (often irrelevant) details on our wireframes and prototypes, after visual designers have enhanced and enriched our designs with elements both beautiful and beautifully useful (well, ideally anyway), the buck will ultimately stop with the technologists.   And Cockburn is one of the technologists and thinkers who is part of forging the path many many of the developers you likely work with or will work with are following.

These are just two books at the edge of UX.  For me, I would really enjoy attending a UX Book Club event discussing books like this, which I think will broaden and enrich our practice by helping us see our practice from the outside.