In my work with software development teams over the years, I’ve struggled to make a significant impact in software usability. No one gets out of bed in the morning with a desire to create software that is excruciating to use, yet we do it again and again. Though the desire to create great products is there, development teams are often at a complete loss as to how to make it usability actionable—how to change the way they work to support usability.
One of the biggest concerns that software usability professionals face is an inability to get in front of the development process. The net effect is that usability is often perceived as an ineffectual bottleneck—an obstacle to be avoided. Given this reality, what can we do as usability professionals to influence our development teams to change the way they think and work to support software usability?
My development team was acquired several years ago by IBM. My team produced solutions that involved both an Eclipse-based desktop application and a web-based runtime environment. At the time of the acquisition, the team had no clear understanding of usability and no best practices in place to ensure ease of use.
Projects were managed in a waterfall fashion and teams were more strongly focused on features than on function. There was an absence of documentation of key scenarios, and although everyone had their own opinion of what was important, that opinion was not always shared across the organization. In short, the development organization was in the Dark Ages when it came to user experience best practices.
The end result was that front-end developers were only concerned with completing their assigned features on time and keeping defects out of their queue during testing. Their concept of quality was limited to code quality. They did not see themselves as being responsible or empowered to ensure a quality user experience, and they were in no way being motivated or rewarded for making improvements in this direction.
Listening to Development Colleagues
After struggling for several years with only limited success at making an impact in this environment, I had an epiphany. Unless, or until, our front-end developers became usability practitioners themselves, we were going to fail. Until developers knew for themselves how to design more usable interfaces, we would never be able to make significant usability gains.
Then I did something that surprisingly didn’t come naturally: I applied user research techniques to my colleagues in development. I wanted to know what the world was like from their perspective and what their primary pain points were in their day-to-day work lives. I basically took the principles of user research and applied them to my colleagues.
I surveyed, interviewed, observed, and listened, and was pleased to see that the feedback I received was highly consistent. In three generic statements, I abstracted the most common comments made by developers:
- “In the beginning of the development cycle, I have lots of time, but I lack what I need to get started. I’m not yet connected with the back-end developers, and the requirements are not fully fleshed out. I’m sitting on my hands not knowing where to begin and watching the days fly by.”
- “Once QA has their hands on the code, all I want to do is get defects out of my queue and keep them out. I just want to be done with it.”
- “There are many front-end developers, and there’s no easy way to distinguish myself from my peers, advance my career, or identify meaningful professional goals for myself. I need to be able to cite something besides, ‘Completed all development tasks in accordance with dates in the project plan.’”
When I overlaid my usability goals on these pain points, I noticed that there was an intersection to be exploited. I saw that it was possible to address the main problems that our front-end developers faced—the aspects of their jobs that frustrate them the most—and improve software usability at the same time. Everybody wins, including our customers.
“Quick and Dirty” User Testing
When looking at the problem of how to help developers to be more productive early in the development cycle, I saw that the one thing they could work on was the interface design. Even with limited details and a lack of connection to the back end, they could still rough out a design and get some initial feedback with what I call “quick and dirty user testing.” This means training developers in the basics of user testing and then having them sit their colleagues down in front of their prototypes early and often to obtain feedback on their design direction—while they still have the luxury of time to do something about it.
I started by identifying developers who were receptive to the idea of participating directly in user testing, and gave them background training information on how to conduct effective user sessions. The majority of training, however, took place within the context of the testing sessions themselves.
Our interaction design is initially documented in wireframes which are included in our design specifications. These wireframes are the first step in the UI development process, followed by prototypes using the product’s front-end technology (in our case, either Eclipse or Flex.)
Initially, I conducted sessions for the developers, choosing new or redesigned areas of the application that had a partially functioning prototype to focus on, and demonstrating usability testing methods. Subsequent sessions would be hosted by the developer while I attended as an observer and coach.
Internal participants were selected who had a variety of knowledge of the product being tested. Candidates were often recruited from the Support, QA, Technical Sales, and Information Development teams.
The format of the session was to briefly introduce each participant to the environment and the purpose of the testing and format. Then we would give them a task or tasks to complete and observe them as they attempted to achieve the stated goal. We took notes on any obstacles or errors the users encountered and what behaviors they expected that weren’t supported. We left time at the end of each session for general discussion.
After the sessions, I worked with the developers on how to present their findings effectively to the team, prioritizing the defects that they identified, as well as categorizing them using our usability best practices (Consistency, Feedback, Preventing and Recovering Errors, etc.).
The investment of time up-front is minimal, and the time it saves later in the cycle is potentially significant. The prototype should not be fully developed; waiting for that would miss the point entirely. Developers can use dummy data and have only a partially functioning interface and still receive a great deal of information about their design from members of other development teams, product managers, technical writers, QA team members, or anyone else with a vested interested in seeing the new design direction as early as possible. Three to five half-hour sessions can yield a significant number of defects.
A New Kind of Results
Those developers who are early adopters of this approach recognize the value it has for them:
- It allows them to balance out their work load over the development cycle.
- It allows them to identify defects early in the process when they have the luxury of time to address them.
- It provides an opportunity to interact with individuals outside of development, increasing their visibility within the organization.
- It provides the chance to present their findings back to the team, demonstrating their focus on product quality, and giving them the chance to exercise their presentation skills.
- It gives them a way to document, in hard numbers, the defects they have prevented from being entered into the code stream.
Nothing is quite as compelling an argument for the importance of usability as watching a user struggle with your interface. When developers observe this—often for the very first time—it can be transformational. It takes the formerly nebulous discipline of usability and makes it something they can see directly and translate into their work.
The benefits are obvious. I’ve watched as a developer, newly trained in user testing techniques, identified thirty usability defects in her prototype. She was so motivated to fix the issues she’d discovered, that she resolved the majority of them before her second test session so she could spend the time identifying new issues.
Hers is exactly the behavior we want to encourage as usability professionals. It has immediate and long-lasting benefits for our developers. Not only are they saving effort in the release they are working on, but they are much less likely to reintroduce similar errors into their code in the future. Also, they are developing an adjunct skill that they can capitalize on for the rest of their careers in software development. Whether they want to become executives, team leaders, or architects, their first-hand understanding of usability testing and its benefits will distinguish them from their peers for the rest of their careers.
Try It for Yourself
This simple method can significantly improve the usability of your products by changing the way in which development teams think and work. We can help our development colleagues not only to work more efficiently, but to reduce the number of usability defects introduced into the code. Moreover, this approach provides front-end developers with a way to distinguish themselves from their peers, create meaningful and measurable professional goals, and enhance their resumes.在看了开发人员的时间表后，Martin 开始在项目早期的定义阶段的“空闲”时间里让团队从一开始就参与有关用户和可用性的工作，从而避免在开发后期出现“没有时间考虑可用性”的问题。除了获取新技能和更可用的最终结果之外，她的开发人员还平衡了工作负荷，提高了在组织中的声望。
文章全文为英文版개발자들의 일정을 살펴보면서, Martin은 프로젝트의 정의 단계에서 일찌감치 “여유” 시간을 사용하여 처음부터 팀이 사용자와 사용성에 관여하도록 하고, 따라서 사이클 말기에 “사용성을 위한 시간이 없는” 중대상황이 발생하는 일을 피할 수 있도록 했다. 새로운 스킬과 더욱 유용한 최종 결과에 더하여, 개발자들은 균형 잡힌 업무량을 할당받았고, 조직에서의 위신도 높일 수 있었다.
The full article is available only in English.Ao analisar os cronogramas dos desenvolvedores, Martin começou a usar o tempo “ocioso” no início da definição de um projeto para fazer com que a equipe se envolvesse com os usuários e com a usabilidade desde o começo, evitando, assim a situação de “não há tempo para a usabilidade” no final do ciclo. Além das novas habilidades e de um resultado final mais fácil de usar, seus desenvolvedores obtiveram uma carga de trabalho equilibrada e um maior prestígio na organização.
O artigo completo está disponível somente em inglês.著者は、開発者のスケジュールに目を向け、プロジェクトを定義する際に、プロジェクトの初期段階の「ダウンタイム」を使ってスタートした時からチームをユーザーとユーザビリティに関わらせることにより、サイクルの最後になって「ユーザビリティに使う時間はない」という逼迫した状況になるのを防ぐことにした。新たなスキルとより使い易い仕上がりに加え、著者のもとで仕事をする開発者たちはバランスの取れた仕事量と組織における高い評判を獲得した。
原文は英語だけになりますAnalizando las programaciones de trabajo de los desarrolladores, Martin comenzó a utilizar el tiempo “ocioso” en la etapa inicial de un proyecto para que el equipo se comprometiese con los usuarios y la usabilidad, evitando así el momento de “ahora no tenemos tiempo de ocuparnos de la usabilidad” al final del ciclo. Además de adquirir nuevas habilidades y obtener un resultado final más usable, sus desarrolladores lograron una carga de trabajo equilibrada y ganaron más prestigio en la organización.
La versión completa de este artículo está sólo disponible en inglés.
