Working with Developers

To follow up on my post about working with designers, here are some tips and things to watch out for when working with developers and engineers.

First Things First

In order to compete on usability, your developers need to have achieved two things.  First, your product must be stable. No design can rescue software that crashes. Second, your product must be feature complete, meaning that all the relevant functionality most important to your target audience is included.  Forced to choose between a product that’s intuitively usable, and a product with more relevant features, customers will almost always choose more features.

Now, it’s still the best practice to integrate usability from the first stages of product development. Just be aware that you don’t get to truly compete on usability until your customers’ needs for stability and features are satisfied.

General tips

Have your developers watch a usability test. Developers sometimes are skeptical about users’ difficulty with certain features, because the functionality is intuitive to them. Seeing is believing here. Don't forget to put what they’re seeing into context. For example, emphasize that users aren’t dumb when they make “dumb mistakes,” they’re just busy, distracted by the system, or unfamiliar with the mental model which the system is based on.

Get involved early. Insert yourself into the development cycle early, when you have the best opportunity to recommend changes before it gets too expensive to change things.

Build relationships. At many companies, developers are a separate tribe. Overcome the barriers and work to build personal relationships, before you have to request them to do some work for you. Invite them out to lunch, strike up a conversation when entering or leaving the office, and seek common ground. The best way to get people to observe your usability tests is to serve snacks.

Lobby for exclusive resources and promote ownership. When developers feel a sense of responsibility for the product's success, user-centered design is an intuitive next step for them.

Here's what you want your developers to be:

• Externally aware. They measure themselves by the best examples they can find, and refer to  competitive threats.
   
• Passionate for their field. You can judge this in several ways. Do they write about their craft in blogs? Attend conferences on their own time?  Take classes to sharpen their skills? 
• Focus on one product area. I prefer a developer who has a lasting role in a product, not a spare part who's constantly being retasked.
• Difficult to distract. I like it when I really have to wave my hands or speak loudly to get a developer's attention. Achieving flow is the key to productivity in most all fields.
   
• Decisive. It’s a lot easier to work with someone who can quickly make decisions when building things, rather than running to a manager every time a new concept arises.
• Won't go home without fixing their bugs. Obviously not everyone can do this, but the best development teams hold themselves to high standards.

On the other hand, watch out for people who are:

• Internally preoccupied or consensus-motivated. If developers are unaware of innovations in their field, or refuse to countenance new ideas, it’s tough to interest them in user experience.
• Apathetic. You want developers to advocate for innovations and positive change, not just do the minimum so they can go home and watch TV.
• Release with obvious bugs in their code. Going back to the stability point above, if you repeatedly uncover showstopper bugs, you start to wonder if the developer cares. You want your engineer to be embarrassed when you find major system bugs. 
• Forced to multitask. Like with any worker, production slows when a developer must switch tasks frequently. Also, multitaskers in software engineering must waste time understanding other people’s code.
• A stickler for business process. Process is important to maintain consistency and quality, but in some organizations it gets out of control.  Process is meant to serve people, not the other way around, so give reality checks when there are too many hoops to jump through.
• Overly defensive. I had a colleague, new to her company, who was having difficulty making herself understood over the phone with a developer. When she acknowledged the communications gap and asked the developer where his cubicle was, so she could come by and explain, he responded, "You don't need to know that."  Red flag!

Of course, many of these points relate to your organization as much as to any specific coworker.

Comments

[Terry Bleizeffer]

Joshua - Your second link ("customers will almost always choose more features") seems to be broken. I can't read the link, but I don't completely agree with that statement - I think it depends on the maturity of the technology. It gets harder and harder to differentiate based on features, so I think what you said in the sentence before is closer to the truth - "all the relevant functionality MOST IMPORTANT to your target audience". If your product has serious holes in core functionality, yeah, usability isn't gonna save you. But once a market matures and most of the products ALL have the core functionality covered, the one with the most non-core features doesn't always win.

I agree with everything you wrote about developers, but I would add one thing: show respect for how difficult development is. It's easy for UXers and developers to form an adversarial relationship, and on the UX side I often see UXers who don't seem to appreciate "life as a developer". Long hours, unrealistic dates, lack of customer contact, constantly evolving technology, only getting recognition when something breaks, etc. It's a tough job. Obviously I think the same is true of UX, and I think developers could do a better job of appreciating us... but it's a two-way street.

Oh, and great point about serving snacks!

**********

Thanks for your comment Terry. I fixed the broken link. Via one of my early blog postings, it points to Donald Norman's infamous article "Simplicity is Highly Overrated."

I support my feature assertion with this and also with my experiences following the sales cycle at my software company. Sales is all about features and look and feel, while implementation and support is all about usability. Since the first area brings in direct revenue, it tends to win -- at least until enough customers stop renewing or repeating.

Your point is well taken about the difficulty of development. --Joshua

[James Breeze]

Hey Joshua,
I'm writing a book on communication between IT and the business. Would you like to collaborate?
James