Myth #4 Usability testing ensures great UI

90% of all usability testing performed on software applications is useless. Ok now that we
have your attention - this is not to say that it doesn’t have a significant role to play in UI
design, but the current culture surrounding usability testing is such that it rarely benefits the
design process.

At Yellowfin we advocate a simple approach, create a shared vision among your
developers and do lots of prototyping. Often we find and solve some of the biggest
usability problems long before they occur simply by discussing, drawing, prototyping and
trialling. So forget the camera, the testing labs and artificial environments, and take
ownership of design at every step of the development process.

Software development is a mix of creativity and code, form and function. With good design it’s
often difficult to tell where area each stops and the next begins. The real questions we try to
answer are, why do users pause? What are they looking at? What are they thinking about?
Did our interface fail them because of the categories we created, the words we used, or is it
the placement of the navigation? Perhaps it’s because of inconsistencies across the
application. Traditional usability testing does not give us these answers.

Usability testing is not quantitative. We do not have scientists in white coats watching mice
running through a maze in our usability labs. Rather we focus on the qualitative aspects of
design. We try to understand how and why people have an emotional response to what has
been created, and, more importantly, how to apply that insight to future development.

Everyone in your company is responsible for usability

There is an outdated notion that usability research requires outside observers who will
somehow comprehend what your users are doing in a more objective manner than yourself.
Usability testing doesn’t require outside firms that hold themselves separate from the design
process. Internalising responsibility for usability means embracing UI research as part of the
design process. It should be performed with the full participation of the development team, so
that everyone can empathise with the user’s perspective. Developing and leading usability
tests should be a core competency owned by everyone within your development team

And it shouldn’t be exclusive to this team. Individuals from across the organisation should
participate. Anyone who might have a stake in what’s being tested should be involved in the
process. If the right people in your company see real users having real problems to which you
can provide solutions, they’ll understand both your value to the client and the need for the
time and resources to make sure that good design happens.

Changing the approach to usability testing also changes what you should expect to get out of
it. Rather than a validation done once before completing a product, this internal, qualitative
usability testing is done earlier, more frequently, and as part of the design process—not
separate from it. This approach allows usability to move from being a one-time, report-
oriented process to an iterative, action-oriented one. This approach also allows you to
always make changes when they’re least expensive.

OK so this section appears to be in direct contrast to involving too many people. Well yes
and no. Primary responsibility rests on the shoulders of a few but anyone who sells, demos
or trains users is encouraged to provide ongoing feedback and suggestions.

Myth #5 Can’t Live without Rigorous Design Processes

Wrong – design methodologies are processes that assist software engineers to engineer
software not to design great software. Design and innovation is first and foremost a creative
process. You can document UML diagrams and functional requirements to your hearts
content but without the people that are passionate about the final outcome, and who are
empathetic to the user, you will be delivering software that has more in common with 2 minute
noodles than your Nona’s Carbonara. Both satisfy your hunger but only Nona’s pasta leaves
you with a sense of fulfilment.

The point here is that if you or your team are not passionate about delivering the very best, or
you have highly bureaucratic processes that hinder creative output you cannot possibly
deliver the best possible software solution.

Processes are required but these like functional requirements have to be balanced against
the creative processes that need to occur for great design to happen. Some internal chaos
and madness can stimulate the creative juices. Continually evaluate the way you develop
software to ensure that you do not place barriers in the way of your developers.

Above all be passionate about what you do!

Copyright © Yellowfin International pty ltd 2006 www.yellowfin.com.au