Comments on: UX and the Reality Problem

By: Rotkapchen

Rotkapchen — Fri, 12 Jun 2009 00:30:58 +0000

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.

By: Anders

Anders — Wed, 10 Jun 2009 18:19:17 +0000

@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!

By: Mark Wagner

Mark Wagner — Wed, 10 Jun 2009 16:30:30 +0000

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.

By: Damon Herren

Damon Herren — Wed, 10 Jun 2009 13:59:04 +0000

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. :)