|
One
commonly held objection to developing a superior user experience,
is that it takes too long. The argument goes that, if you wait to
get it right then you'll be late to market and the opportunity will
be lost. The objective isn't to say "Ready! Aim! Aim! Aim!
Aim! Aim!, Fire", but "Ready! Fire! Now adjust your aim
for effect..." In this short white paper, we present an approach
which allows you to do both in a controlled and reasoned fashion
- move quickly to respond to market demands, whilst developing a
superior user experience.
Objections
Why
should there be an objection to User Centered Design and developing
a superior user experience. Surely, it makes good business sense?
The answer is simple! To do it properly, you have to engage a usability
professional or analyst to develop contextual analysis. Perhaps
you have to use your imagination and develop imaginary personas
based on target demographics. Next you develop a user interface
prototype, perhaps as part of a participatory design process. Together,
the designers, usability professionals and clients have devised
what they think is THE answer.
The
next stage would be to run a series of usability tests on the prototype,
quickly iterating the design as results are collated from testing.
This was discussed earlier this year in "Evangelize
with Usability". Finally, when all the tests are run, the
prototype is validated and everyone is happy. Then and only then
is it time to write the formal requirements.
That
process may have taken anything up to 6 months, even in a relatively
fast environment. Meanwhile, the opposition launched an inferior
product.
Throwing
mud at the wall
The
alternative to a properly designed user experience, is what Jakob
Nielsen has referred to as the "throw some mud at the wall"
approach to usability. In this approach, the vendor simply ships
something which delivers functionality and watches to see what happens.
Where there are problems, they make a change with the next version
and watch again. They keep making changes at a whim until the design
and the product finally settles down or disappears.
Throwing
mud at the wall isn't a strategy. It's putting your success in the
hands of the gods.
Adopting
a two track approach
The
answer is to adopt a two track approach and run both tracks in parallel.
The first track is tactical. The second strategic. The strategic
track involves a full user centered design process and the development
of a superior user experience, but what might the first track, the
tactical track involve? A possible answer was hinted at by Alan
Cooper in his interview
with uidesign.net, earlier this year.
Business
tends to look at the competition. Technology people tend to look
at yesterday's technology and extend it.
What
Cooper is saying here is that technical people tend to look at technology
and think, what is possible? "what changes or improvements
can I make through existing technology in order to deliver a really
cool product?" Meanwhile, business people / marketing people
tend to be thinking, "what is the competition doing? should
we be doing it too? what can we add to our laundry list of functions
to outperform the competition?"
This
provides the answer. This tells us how we can move forward, bring
product to market, keep many different and diverse functions of
the business happy and still bring a superior product with a good
user experience to market. We must develop the superior product
in parallel whilst focusing tactically on what is possible and what
the competition are doing. Striking a balance between allocation
of resources across the tactical and the strategic initiatives.
The
two tracks
|
Track
1
|
Track
2
|
|
Tactical
|
Strategic
|
|
Step
1: Technical Functionality
A
combination of technical folks and strategic marketing analysts
devise a laundry list of functionality
The
functionality is assessed and categorized. The most important
and desirable features are formed into the specification
for Release 1.0
Step
2: Release 1.0
Set
the development team to work designing, writing and testing
code. Release the result when ready.
Step
3: Competitive Analysis
Product
Management completes a competitive market analysis
A
list of functionality being offered by competing products
is obtained and these are assessed and categorized. Those
deemed essential for a second release are added to a new
laundry list of features for the next release of the product.
Step
4: Technical Functionality, again
Repeat
step 1 and add the results to the list from Step 3.
Step
5: Release 2.0
Release
2.0 is developed based on the requirements from Step 4.
Step
6: Transition Plan
By
this time the design for Release 3.0 from the strategic
track should be well developed. It is now time to make a
transition plan.
Have
the ui design team, analyse the functionality and look and
feel from the 3.0 release. Set out a series of incremental
functionality additions / deletions and design changes for
up to 3 releases.
Call
each of these iterative interim designs 2.1, 2.2 and 2.3
respectively. Plan to release them in a controlled fashion
to fill the time gap until 3.0 is ready.
The
result should be seamless to the end-user and will hopefully
look like it was your plan all along.
Step
7. Develop the transition releases
Develop
2.1, 2.2 and 2.3 and release them to the scheduled dates.
|
Step
1: Define Target Market
Ask
the business or marketing people to select a target or series
of targets for the new product or service.
Step
2: Conduct contextual inquiry
Conduct
contextual inquiry with people who match the target market
definition, or, devise imaginary personas which meet the
target market definitions.
Step
3: Take Lifestyle Snapshots
Using
the lifestyle snapshot
technique from an earlier white paper, analyse the personas
and devise a list of scenarios in which the new technology
may be able to assist and add value to the lives of the
target market personas.
Step
4: List functionality
From
the list of scenarios, extract a list of functionality.
Step
5: Analyse the functionality list
Assess
the functionality into categories based on the following
criteria: Desirability from a marketing perspective; Technical
risk/difficulty; availability of the functionality or supporting
functionality.
For
example, it may be highly desirable to deliver a product
which reads your mind, but before the invention of ThoughtML,
it will probably not be possible. Therefore, desirability
would score highly, but technical difficulty and availability
of supporting technology would rule out inclusion of such
a feature or set of features in a product.
Step
6: Write the Requirements
Now
revisit the scenarios and categorize them based on the functionality
assessment. A new list of scenarios which are practical
to develop and desirable from a marketing perspective should
emerge.
Step
7: Conduct a full lifecycle development process
Proceed
to develop Release 3.0 of the product using a full lifecycle
user centered design approach such as that developed by
Deborah Mayhew
or Larry Constantine.
Step
8: Release 3.0
Having
conducted a proper ,full lifecycle development process,
release the strategic product after full and thorough testing.
It should appear to be the seamless replacement for the
earlier tactical products 1.x and 2.x
|
Resources
A
key issue to making the two track approach work, is the assignment
of resources over time. It is essential for the management to realize
that the 2nd track requires only a few staff in the early stages.
Perhaps as few as 3 people can make significant progress on track
2. What is required is an interaction designer / analyst, a prototyping
developer and a usability engineer. Additional resources are always
helpful, if the requirement is likely to be large. However, a minimum
team of three should suffice to gather requirements from stakeholders,
build the lifestyle snapshots, develop initial prototypes and then
run a series of early lifecycle usability studies, iterating the
design.
Meanwhile,
another small team of developers with a sufficient critical mass,
perhaps as few as 6 or 8 can build the first release for the tactical
track.
At
the point when Release 1.0 hits the streets, suddenly more man power
is required. A full development team is needed to develop 2.0 and
perhaps maintain 1.x. Meanwhile, a full analysis team is required
to write the requirements for 3.0.
This
graph loosely shows the allocation of personnel to either track
over time.

Figure
1. Graph showing approximate relative resource levels
during the two track period
Operating
Twin Tracks
It
is also important to realize that the two tracks shouldn't operate
in silos. It is important to synchronize the effort periodically.
Terry Simpson has referred to this as "the ladder model"
as opposed to a two track model. The rungs of the ladder represent
synchronization points.
It
is also important to separate out the notion of tracks of work from
dedicated personnel resources. For example, if you have a talented
individual with, for example, a flair for good design, why not allow
them to jump between tracks, doing design work for both sides.
Summary
Good
user centered design can be seen as a luxury. A luxury which is
hard to justify when trying to run on web time. Even the enlightened
manager might say, "You know, we realize that user experience
is SO important to our business but how is it possible when we are
constantly stretched at full capacity?"
Alan
Cooper believes
that
good Goal-Directed Design allows you to produce release 3 quality
in the release 1 timeframe.
However,
building that understanding of the user, which is a prerequisite
for any form of user centered design, does take time. You can buy
yourself that time by advocating a two track approach for your organization.
In
this White Paper, we have hopefully demonstrated that two tracks
is an approach which will be broadly acceptable to all interested
parties working inside an internet vendor. An approach which facilitates
fast rapid releases, early time to market, addresses competitive
concerns and still leads to a superior user experience, designed
with the user in mind.
Acknowledgements
Thanks
to Terry Simpson and Carlye Marsteller for reviewing and commenting
on this article. Very much appreciated.
|