User experience design fails if it ends with a picture

Designs fail when the user experience stage ends with a picture and some words. Yet we so often leave that wide chasm between what is intended (and often tested) and what gets built. UXers need to have a firm grasp of what it takes to implement a design and the know-how to guide and even work with developers. Or better yet (in certain cases) be the developer. Creating an elegant front-end experience takes much more than even the most cohesive design requirements document. The micro-decisions made by front-end developers are what allow a design to evolve into experiences.

These are two stories of my early career where i concluded that I needed to know the code behind anything i designed.

Making a circle fit a square…

The first web design i worked on, 12 years ago, had a circular navigation scheme. A large arch that the navigation was attached to like leaves on a vine. I’m not talking curvey left nav — it was a circle. It looked cool and the client dug it. Then we got the news from the developers. I learned that the web thinks in rectangles and squares and this design gave them nightmares.

But, God bless ’em, they struggled through and built this intranet for this rather large company with this rather… unique design. I sat by their sides and saw what it took for them to code the design and solve complex layout challenges. I think they enjoyed the challenge a bit, but they were a special breed.

While that site was being developed I studied the 1100 page HTML Black Book cover to cover. I did every excercise. Even the ones that make text blink and other sizzle-ating tricks. That enabled me to quickly recognize when a design was pushing the limits of feasibility. It also allowed me to walk that line with more confidence.

Connecting the dots of the experience…

For the next project (different crew) I was going to be on top of my game. No unsliced jpegs being sent this time. I was going to package up the materials to build this project. So I did. I sliced it up the way that I would expect any coder to slice it up. Lots of rectangles and squares. Cutting off corner images and laying out tables upon tables. Nesting nesting nesting. (this is why i am brushing up on my CSS). Also included were in-depth descriptions with storyboarded transitions. This was going to be slick.

I sent the package of code and images over to the development team. Then radio silence. Several weeks later the experience was revealed. Gah! My heart sunk. Several things happened. The real content made the design break apart in ways i did not anticipate. Perfectly aligned tables suddenly were not. What’s worse – the transitions did not behave correctly. Well they behaved, but not in a way that enhanced the experience. They were jarring at times.

The developers on this project gave it a go, but the experience never lived up to it’s intended nice-y-ness. The layout was fixed but the polish was lost.

The polish is the design

12 years later the story is very much the same. However, users expectations are getting set higher and higher by designs that understand how transitions and elegant responses can enhance a user experience. That means traditional tools used to communicate experience design need to be enhanced with real code and real examples (as opposed to replaced). Not just to communicate with development teams, but to test the actual experience. The one where things open and close and fade and appear… and even blink… no, don’t make them blink. seriously.

Advertisements

2 thoughts on “User experience design fails if it ends with a picture

  1. Still trying to figure out the best way to share designs with tech. Wires, prototypes, interaction patterns. Whatever we give, it still requires a lot of real collaboration to get things done right. A lot of “you gotta move that to the right…that’s not supposed to open that way…that modal’s too big.” Specs are great, a good relationship with the developer is priceless.

    • Agree totally about a relationship with the build team. I read a very nicely worded post about building those relationships i will try to find for sharing. Another key partner can be the QA team. The better they understand the intent – the more they can flag issues beyond bugs.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s