The Magazine of the Usability Professionals' Association
By John Schrag
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:
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:
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.UX
John Schrag is senior principal interaction designer at Autodesk. Specializing in interface design for artistic users with open-ended tasks, he has helped create 3D graphics tools for graphic artists, typographers, industrial designers, automotive stylists, animators, sculptors, filmmakers, and architects. He has presented at various conferences, including UPA and SIGGRAPH.
Usability Professionals' Association
promoting usability concepts and techniques worldwide
User Experience Magazine is by and about usability professionals, featuring significant and unique articles dealing with the broad field of usability and the user experience.
This article was originally printed in User Experience Magazine, Volume 11, Issue 1, 2012.
© Usability Professionals' Association
Contact UPA at http://www.usabilityprofessionals.org/about_upa/contact_upa.html