Usability and User Experience Resources
Idea Market Afterthoughts 2004

Where Does Usability Fit in the Software Lifecycle?

Activator: Karen Bachmann

• What are the key phases and related usability tasks in a typical development life cycle?
• When in a schedule crunch, which tasks are "must completes" and which will get dropped?
• How do you communicate the usability priorities in each phase to management?
• When do you start each task in relationship to the overall development effort?

Summary

The base question was really a step beyond the reality most participants faced in their workplaces. In many organizations, the real question they faced was "Can usability fit in the development life cycle?". Most recognized the value of getting involved as early as possible to have the greatest affect, although their first opportunity to include usability often came at the end of the life cycle. The experience of most participants suggests that the effort to have usability become part of the life cycle in an organization may take many years.

Collected Comments

The collected comments are generally not edited from the notes taken during the session. If words were omitted in the notes and their omission would impair understanding of the comment, the words are added here.

• Management is willing to sacrifice testing and more robust documentation when facing a schedule crunch.
• Even if you can communicate usability priorities, how do you prevent sacrificing "must haves"?
• Reference information for a product often gets dropped.
• Take an existing methodology and figure out where usability can fit.
• Tend to put usability at end because it made sense in the organization.
• Usability happens at the end because the development organization does not create the user interface until the underlying mechanisms are in place. This approach is changing as the organization implements the Rational Unified Process.
• Developers still believe they are responsible for and capable of developing UI prototypes.
• Is usability part of the information design and analysis phase? General consensus was yes, definitely.
• Usability is not considered outside the functional requirements. Developers may touch on it but focused on developing the user interface.
• When writing functional requirements, the documentation and usability teams are present at meetings, but are not actively involved.
• Nothing is documented about usability to inform design and test phases.
• Present at the table during the early phases, but not given a strong voice to make comments.
• Some developer express sentiments such as "users are stupid" or "just document serious usability problems" and will not change the UI to help the users.
• QA is involved in the requirements. Usability advocates should partner with QA to increase stake in initial phases. Even if we do not have formal involvement, we are getting the message out.
• What is the point you step into the process? More experienced usability practitioners can step in earlier in the life cycle with greater diplomacy.
• Diplomacy is key to being successful.
• Battle between changing the UI (the developers’ job) and changing the documentation (the technical writers’ job).
• The "trick" is changing before coding.
• User interface development is so late in the process that change is painful.
• What about paper prototyping? Developers think developing in a programming language is easier and try to block any other type of prototyping.
• Need organizational buy-in for processes.
• Developers want to do the design and resist letting a usability advocate do it.
• Usability practitioners are called in after the coding is done.
• Usability is not in the process and processes are unique to departments not shared as a higher level—QA has theirs, documentation has theirs, and nobody has usability.
• We need to piggyback usability on existing processes.
• Project teams are not aware of usability to ask the right questions.
• We need information from the team to inform usability tasks.
• Using the word "usability" for a couple of years to raise awareness and gain traction for implementing it.
• User support could be reduced if usability were considered earlier in the project decision-making.
• While this seems to be a no-brainer, some organizations consider customer support to be a revenue center.
• If customer support generates revenue, companies may be reluctant to change the product to be more usable.
• One argument against this thinking is that usability will sell more of the product, offsetting any loss to customer support revenue.
• Support revenue is often a fixed amount. Usability may provide a greater profit margin.
• Companies frequently do not have the financial data to understand the benefits of usability on the front end versus customer support revenue at the end.
• We need to collect data to show organizations the before and after pictures of how usability benefited a project.
• We need more academic studies to prove the value of usability tasks.
• How do you make clear that an issue is the usability of the product not a documentation bug?
• Able to put usability testing in the schedule between alpha and beta releases. The usability tasks are still not well-defined.
• We need to usability test cases. We should clearly differentiate usability testing from beta testing.
• One problem is that many organizations do not have a usability team.
• User education is expected to encompass all aspects of usability.
• Some participants were able to get feedback relatively easily.
• Usability is the only answer for numerous questions from end customers.
• Developers misunderstand users.
• Developers still resist usability even when shown the data.
• Making progress with even one developer sometimes takes a lot of hard work.
• Comments could not be provided until the initial user interface was coded.
• Usability team was not allowed input into the design process.
• Often there is no distinct design phase to even be involved in.
• Usability needs to be part of the envisioning phase.
• One participant found it easier to apply usability principles after the initial design by the developers was completed.
• Many comments at this stage are useful for enhancements.
• Developers will do what is easiest to implement, not necessarily easiest to use.
• We need GUI design standards/style guides.
• More guidance is needed for websites.
• Even when standard look-and-feel is used for individual screens, the whole product may still not be usable when those screens are integrated at the end.
• Marketing would own the process (for example, legal use of logos).
• Navigation and information architecture are not part of standard guidelines.
• Usability standards are needed.
• Usability advocates gain inroads with programmers for whom English is a second language. These programmers seek vocabulary help, giving us a chance to promote more fundamental changes. In one organization, technical communicators are part of the review process.
• Sitting with developers to make the changes is helpful.
• Ideally, we should create a prototype or mock-up before real code is written.
• One possible avenue to get involved is to have technical communicators work to create usable error messages to improve the experience. Management at one company has bought into this approach.