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