Why user experience people need to roll up their sleeves and get their hands dirty in development to get the best results.
In an email exchange with a friend this morning he was speaking about his involvement on a soon to be released product. He’s been working on that product to design its user experience. He’d recently made a tactical change that I’m beginning to consider critical for the success of a software product.
In support of my friend’s user experience work he’d built user interface prototypes, storyboarded usage scenarios, and validated those prototypes with prospective end users. All seemed well. But something funny happened on the way to implementation. The team members building the product had their own ideas about what the product should be. And those considering the direction of the product believed that a strategy change was in order. If you’re a fan of Garrett’s Elements model, you know that a strategy change changes everything.
There wasn’t time for the team to go back and re-create UI design. The team was composed of really sharp people. I know most of them, and they truly are rocket-science smart software designers and developers. They succeeded in creating a product that was technically sound and innovative, but only sorta usable, and, well, not so sexy.
Meanwhile, the release date looms closer.
Give up and get started
After several rounds of reviewing the product and giving specific feedback on how to change it to make it better, the decision was made to give up.
By give up I mean for my friend to give up on giving feedback, roll up his sleeves and get his hands dirty in the development of the software. For him this meant taking ownership of CSS, directly editing XHTML, and where necessary editing underlying Ruby code. His hands were sorta dirty before – but much dirtier now. “I’m feeling much more positive [about the product]” my friend reports.
My friend’s story is one I’ve hard, seen, and been a direct participant in many times – enough that I’m willing to declare it a critical success pattern for product design and development.
The tactical technical UI design pattern
Where I’ve seem product design be most effective, User Experience types are directly involved with day to day development.
They work on the requirements side to help define what the product does. They collaborate with developers to help them build functionality. No one expects the developers that build functionality to make it work well and look and feel good to use. The look and feel good part is done by a tactical, technical, user experience person.
This tactical technical UE person might be a developer by trade, or UI designer with enough technical background to load up the development environment and directly manipulate code to massage the user interface.
You really gotta do this.
The truth is that it’s tough to predict exactly how the real code will behave once you start using it – see it animated and under your control as a user. Details about what should be in the user interface always arrive late – details that affect the layout and page or screen design. And, there’s always late breaking great ideas. Stuff you thought of in the morning shower, or saw a competitor do in their website. There’s no reason to follow your original design, if you’ve discovered something better.
What’s more, a user interface design conceived by someone without detailed understanding of the tools used to construct it often suggests good, but expensive to implement designs.
There’s a sweet-spot between good, and expensive to build that we’re often looking for. Ideally, we hope to find a design that’s best to use and cheapest to build. Without having a healthy understanding for how to build it, how could one find that spot? One would hope aggressive collaboration – even pairing at the development workstation might help.
The left-brain and right-brain in separate heads anti-pattern
I’ve often observed the “smell” in projects where the abilities to design the outside of the software, and the abilities to manipulate that design in code don’t exist in the same head. I’ve seen lots of hours wasted, and lots of frustration trying to communicate the importance of moving this label 5 pixels to the left. I’ve seen developers angry when a designer asks them to relocate an element of a screen, only to reverse that decision after seeing it.
Sadly, fine grain design, the stuff that really makes a big difference in the perceived quality and actual usability of a product, requires lots of trial and error.
I have seen successful organizations where the designers were indeed separate people from the developers. But, the developers in these sorts of organizations, measured against the average developer, are strong designers. They can make fine-grained – 5-pixel-to-the-left – adjustments without prompting. They understand design well enough to be tolerant of the trial-and-error cycle. They understand design well enough to make changes based on very little guidance from designers. They understand design well enough to bring their own ideas and innovations to the product. While their left-brain may be a bit heavier than their right, their right is strong and fully engaged – and supported by design knowledge, skill and practice.
Good UI design can’t be communicated in a document
I don’t believe a good UI design can be communicated in a document. It may look good on paper. But the translation of that design to a working product will always result in some change – changing not easily predicted and written in the document.
Staff a tactical, technical designer
If you want your product design and development to be effective, put someone on staff who’s both a strong designer and technically capable of making design changes to the product directly.
If you’re a frustrated designer, look for a way to roll your sleeves up and get your hands dirty. Can you learn the technical skills yourself? Can you collaborate with a developer who has the right raw material to become a good designer?
If you’ve had success with your product by having tactical, technical UI designers on staff, I’d like to hear about it. If you’ve had success without them, I’d like to hear about how your process works to accommodate that. And, if you struggle with the connection between UI design and product implementation, I’d love to hear some horror stories. Please get in touch with me.