Whether your development practice is Agile, staged, or waterfall, and no matter what software domain you work in, one thing is true: the developers always have the last word. If they don’t write the code for your desired interface changes, then your changes don’t go into the software. In this sense, it doesn’t matter if you are “right” or if you can argue your point with mounds of test data—at some point, you have to convince a developer to make the change.

I hope we all work on well-functioning teams where we collaborate well with our developers, and where they want, as much as we do, to create usable, beautiful software that will help users succeed in whatever they are trying to do. But at some point in every release cycle, the team runs low on time and resources, and things start to get cut from the schedule. The first thing to get cut, usually, is the work that improves the usability of the software, especially in cases where you are doing “remedial” usability work on existing features.

Leftover usability work gets cut because of the way that development managers have to prioritize fixes. The first priority is crashes and problems that cause data loss, followed by bugs where things don’t work correctly. Of that class of bugs, problems where the users have a viable work-around to achieve their goals are pushed to the bottom—and that pretty much includes all usability problems.

This is an unwinnable argument. While it is true, and developers will agree, that you must have a certain amount of development time set aside for usability concerns, when it comes to bug-by-bug comparison, usability loses out. It is difficult to successfully argue that it is more important to re-layout a dialog to make it more understandable than it is to fix a crash. One can try to argue that an unusable feature is broken, but as long as doing the task is technically possible—no matter how difficult—it will be considered less important to development than a task that can’t be done at all.

This should be no surprise; developers and development managers are generally rewarded for producing code that is stable, functional, and on time. UX practitioners are rewarded for the usability and effectiveness of our designs, although, in the end, we don’t really control how they end up in the software.

Changing the Terms of Engagement

Having a developer on the UX team provides a different way to split development time between different needs. Instead of dividing up the work by time, you divide it up by people; the dedicated UX developer spends all of his or her time doing nothing except working on the usability agenda for a product.

Whether or not this strategy will be effective depends largely on the reporting structure of the project team. If the UX developer is a member of the main development team on loan to the UX agenda, it probably won’t work. As soon as the inevitable time crunch comes, this developer will be “borrowed back” to fix crashes and “real” bugs. Also, if the developer reports to the UX team members who report to the development manager, the same thing is almost certain to happen.

Our company division has a standalone UX team that acts on a consultancy basis to other projects, loaning out our interaction designers (and our dedicated developer) as needed. Since our developer is on a different reporting chain entirely, he or she cannot be annexed by the agenda of other projects when resources get tight. This is a critical success factor.

In our internal consultancy setup, when our developer is assigned to work with an interaction designer on a project, the development manager of that project is usually overjoyed at the prospect of having an additional developer, even one they don’t fully control. This is especially true if that developer isn’t charged to their budget.

The Kind of Developer You Need

Since your developer will be mostly working on user interface code, you don’t need someone with deep expertise in the domain field of your users or with particularly esoteric engineering skills. We find junior programmers fine for this work, because they are generally flexible and eager to acquire new skills, and will listen well to direction.

For years, our team has relied on co-op (intern) engineering and computer science students from a local university, for several reasons:

• They are relatively inexpensive and, therefore, easier to argue for when setting a budget. Depending on your company, they may also come out of a completely different budget, since they don’t represent new permanent head count.
• Although they rotate for four-month terms, they are available all year and are thus a full-time development resource.
• Your commitment is only for one term at a time, so you can try this strategy once to see if it works for your team. If it works, you can then get interns sporadically as needed—although you do need to plan a few months ahead.
• It’s a great way to scout upcoming talent you may want to hire full-time later on.
• It exposes computer science and engineering students to the importance of usability and interaction design, which can only benefit all of us in the long run.

Deploying Your Developer

Now that you have your co-op/intern developer and a project you want to use him or her on, what is the best way to do it? The first and most important thing is to negotiate with the development manager to set the terms of involvement and support. Specifically:

• If there are no senior developers on the UX team, the development manager will have to assign someone to act as mentor to your developer. This mentor will be responsible for helping your developer find his or her way around the code base, learn the local development/coding practices, debugging tools, and so on. While this represents some overhead, the advantages to the development manager are well worth it.
• You need to clarify that you will be setting the agenda for this developer, and that this will be limited to things that affect usability and user experience. Of course, the development manager has final say over what gets into the code base, and quality standards for code, which your developer must live up to.
• You should agree that your developer will fix any bugs that he or she introduces. But your developer will not be responsible for fixing every UI bug, just because it’s in the UI. (You may, however, assign particular UI bugs to your developer in cases where they have a negative impact on the user experience and are unlikely to be fixed otherwise.)
• Your developer will also not be responsible for writing all the UI for all the new features. That should be the responsibility of the programmer coding each feature. (Later, when the time crunch comes around and key UI features are not being finished, you can get your developer to finish the key areas. But don’t announce up-front that you’ll do that, or the other coders will pay no attention to UI whatsoever.)

Your developer will also need appropriate hardware and a desk to sit at. The best way to budget or obtain these items will, of course, be particular to your workplace. If possible, have your developer sit with your interaction designers and not with the developers. This may seem to go against current ideas of co-location, but in our experience it is wiser. People pick up information and values environmentally, so if your developer is located with the interaction designers, he or she will be overhearing discussions about the user experience problems and how to improve on them. Located with the developers, he or she will be immersed in that milieu, and might “go native.” You want to ensure that your developer feels a part of your team.

If your developer is not near you, other members of the development team may start slipping additional work to your developer under the table. Junior developers may not know how to say no to such requests, and you may not realize it is even happening until you have lost a lot of time. Sitting close makes it more likely you will catch these situations.

Ways to make sure your developer feels a part of the UX effort include inviting him or her to sit in on some of the testing, making sure you explain the rationale of changes you ask him or her to do, and praising the work when it does measurably improve the interaction. Even if it was your design, the developer made it happen and should feel an equal stake in the success.

The Kind of Work to Give Your Developer

The best strategy is to give your developer high value UX work that is least likely to be done by other developers. For example, if you have designed the UI for a new feature that is on the development plan, you can be fairly certain that the development team is going to build it whether or not you loan them your developer. So this is not a good job for your developer. Let the regular development team build it.

On the other hand, say you have performed a usability test on existing shipped software, and you come up with a list of forty small label and interaction detail changes that could really enhance the overall usability. Even though these are all small, easy, low-risk fixes, chances are that they will be pushed down the priority list below new features, then below crashes and other bugs. (Then, when the time crunch comes, they will be pushed off to the next version.) These kinds of changes make excellent jobs for your developer, who can complete a large number of them in a relatively short time. The development manager will also be glad to get a bunch of small, pesky bugs off the table.

Sometimes there are features that development is willing to put in, but only in the most minimal form. You can have your developer finish those properly. (Again, don’t pre-announce that you will be doing so. Assign that work after the feature is in.)

Outside of production coding, you can use your developer to help you create code prototypes for usability testing in those circumstances when low-fidelity prototyping is not feasible (for example, for highly-interactive interfaces where the visceral feel of the interaction is paramount). This is a key benefit of having a UX team developer, especially if you practice formative usability testing. Without disturbing the development team at all, you can try a number of different interactions, and then pass the prototype code onto the development as a specification.

Topics: Software Development, Teams, Collaboration
Published in: March, 2012 in Beyond Books