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.通过给您的 UX 团队增加一名开发人员，您可以改善合作条件，一并绕过调度和安排工作先后问题。这样不必按时间来划分工作（先来排除程序中的错误，然后再纠正可用性问题），而可以按人来分工作（Joe 排错，同时 Maureen 纠正可用性问题），从而保证对可用性问题的关注。这篇文章详细介绍了这一构思，并为任何想要尝试此方法的人提供了具体的指导和建议。
文章全文为英文版당신의 UX 팀에 개발자를 추가하면 업무 조건을 변화하고, 일정과 우선순위 문제를 함께 피할 수 있습니다. 업무를 순차적으로 분류(버그를 우선, 사용성 수정은 나중에)하는 대신, 근무자가 동시에 일을 추진할 수 있음으로 해서(조가 버그를 조정하는 동안 모린이 사용성 문제를 조정함) 사용성 문제에 관한 관심이 특정한 수준을 유지할 수 있게 보장합니다. 본 논문은 이 아이디어를 확장하며 특정 지침을 제공하고 이 접근법을 시도하고자 하는 자에게 조언을 제공합니다.
The full article is available only in English.Ao incluir um desenvolvedor em sua equipe de experiência do usuário, você pode alterar as formas de envolvimento e ultrapassar problemas de cronograma e prioridades ao mesmo tempo. Em vez de dividir o trabalho por tempo (bugs primeiro, resolução de problemas de usabilidade depois), o trabalho pode ser dividido por pessoa (Joe resolverá os bugs enquanto Maureen resolverá os problemas de usabilidade), assegurando um determinado nível de atenção aos problemas de usabilidade. Este artigo desenvolve essa ideia e fornece orientação e conselho específicos para todos que queiram tentar essa abordagem.
O artigo completo está disponível somente em inglês.UXチームに開発者を加えると、調査への取り組みの条件を変えることができ、スケジュールや優先順位の問題を一括して避けられる。(まずバグを修正して、後でユーザビリティを修正する、といったように）作業を時間の流れで分けようとせず、ユーザビリティの問題にある程度の注意が払われるようにするため、関係者ごとに作業を分けるのが良い（例えばモウリーンがユーザビリティの問題を修正している最中に、ジョーはバグを修正する、といった具合）。この記事では、このアイデアを拡張し、このアプローチを取り入れたい人に向けた具体的なガイダンスやアドバイスを提供する。
原文は英語だけになりますMediante la incorporación de un desarrollador a su equipo de UX, usted puede cambiar las reglas de participación del equipo y sortear los problemas de la programación de tareas y las prioridades al mismo tiempo. En lugar de dividir el trabajo en función del tiempo (primero los errores críticos, luego las correcciones de usabilidad), el trabajo se puede dividir por persona (Joe va a solucionar los errores críticos mientras Maureen soluciona los problemas de usabilidad), con lo cual se garantiza un cierto nivel de atención a las cuestiones relacionadas con la usabilidad. En este artículo se amplía esta idea y se brinda orientación y consejos específicos para todos aquellos que quieran poner en práctica este enfoque.
La versión completa de este artículo está sólo disponible en inglés.
