reasons not to do usability retrospectively?

26 Feb 2007 - 8:33am
7 years ago
5 replies
368 reads
Daniel Williams
2005

reasons not to do usability retrospectively?

I have currently been asked to make usability recommendations upon an
application which is late in the development phase and almost ready for
release to the user community. I'm looking for reasons why User Experience
is not a retrospective activity and should be built into the product from
the start e.g. Lower cost to make changes etc. What other reasons can anyone
think of?

Much appreciated

Dan

Comments

26 Feb 2007 - 9:28am
Ivo Domburg
2007

Dan,

This is an point I try to get across to most my clients (mostly in
software engineering) all the time. One of the problems is that
clients with a background in engineering often see usability as
'skinning of the product'. I think part of our job is to convince our
clients that having a usability designer on the team from the first
day on speeds up the development process and increases the quality of
the product.
The most important point I try to make to my clients is that having a
usability designer on the team helps all members on the team to see
the consequences of their concepts for the end user in an early stage
of the process. It helps to make the discussion more concrete, and
that will speed up the process.
Coming from a graphic design background myself I am used to present
my concepts rather in images than words. This also helps the team
members to force themselves to see the consequences of their
concepts. A few images (flowcharts, wireframes, screen sketches) work
better than a lot of words to get the discussion going and keep the
team focussed.

Best regards,
Ivo

On 26-feb-2007, at 14:33, Dan Williams wrote:

> reasons not to do usability retrospectively?
>
> I have currently been asked to make usability recommendations upon an
> application which is late in the development phase and almost ready
> for
> release to the user community. I'm looking for reasons why User
> Experience
> is not a retrospective activity and should be built into the
> product from
> the start e.g. Lower cost to make changes etc. What other reasons
> can anyone
> think of?
>
> Much appreciated
>
> Dan
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

26 Feb 2007 - 1:41pm
Dave Malouf
2005

Actually, the shooter might get hurt more in that scenario due to the
ricochet. ;)

-- dave

On 2/26/07, Ari Feldman <ari1970 at gmail.com> wrote:
> good analogy...but what if that card board happened to be spun from high
> tech carbon fiber and the gun is a .22? then, there's a chance you might
> live!
>
> :-)
>
>
> On 2/26/07, Dante Murphy <dmurphy at mbcnet.com> wrote:
> >
> > I would illustrate this point by handing the client a thin piece of
> > cardboard and telling them--
> >
> > "I'm testing this bulletproof shield. Hold this in front of your
> > chest..."
> >
> > _______________________________________
> > Dante Murphy | Director of Information Architecture
> > Medical Broadcasting Company | A D I G I T A S INC. COMPANY
> >
> > Subject: [IxDA Discuss] reasons not to do usability retrospectively?
> >
> > reasons not to do usability retrospectively?
> >
> > I have currently been asked to make usability recommendations upon an
> > application which is late in the development phase and almost ready for
> > release to the user community. I'm looking for reasons why User
> > Experience
> > is not a retrospective activity and should be built into the product
> > from
> > the start e.g. Lower cost to make changes etc. What other reasons can
> > anyone
> > think of?
> >
> > Much appreciated
> >
> > Dan
> > ________________________________________________________________
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
>
>
>
> --
> ----------------------------------------------------------------
> http://www.flyingyogi.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
David Malouf
http://synapticburn.com/
http://ixda.org/
http://motorola.com/

26 Feb 2007 - 1:47pm
Nasir Barday
2006

Dante, paper prototypes are no laughing matter ...

- Nasir

26 Feb 2007 - 1:23pm
Will Parker
2007

I haven't got time to do a full rant, but I'd direct you to John
Gruber's excellent essay, 'Ronco Spray-on Usability' (http://
daringfireball.net/2004/04/spray_on_usability), wherein he details
the problems associated with the assumption that UI design is
something that happens _after_ the main development phase.

- Will

Will Parker
wparker at ChannelingDesign.com
206-228-3187 (cell-preferred)
206-783-1943 (home office)

"The only people who value your specialist knowledge are the ones who
already have it." - William Tozier

On Feb 26, 2007, at 5:33 AM, Dan Williams wrote:

> reasons not to do usability retrospectively?
>
> I have currently been asked to make usability recommendations upon an
> application which is late in the development phase and almost ready
> for
> release to the user community. I'm looking for reasons why User
> Experience
> is not a retrospective activity and should be built into the
> product from
> the start e.g. Lower cost to make changes etc. What other reasons
> can anyone
> think of?
>
> Much appreciated
>
> Dan
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

26 Feb 2007 - 10:23am
.pauric
2006

In my experience with this type of 'tell us how to make it prettier, but
dont add to our timescales' scenario, you run the risk of alienating user
focused design from development if you ask for a re-work of aspects
completed early in the project, the changes usually go far deeper than the
UI. This can be quite disruptive and do not forget that if the project is
'failing' the last thing needed is a straw that breaks the camels back. It
will be labeled as too much too late, in the end nothing is accomplished.

My take is that you now have an audience that recognizes their mistakes, the
need for user input at the start of a project, but who are also facing a
hard stop. I would leverage those who asked for help as much as possible.
I take this three pronged approached when faced with this problem, working
on each initiative concurrently;

1) Detail the quick fixes that will make the best of a bad job.
2) Talk to management about changes in the process needed to avoid this in
the future
3a) Initiate usability testing on the current project to be ready for the
next revision
OR, depending on project/resource commitment
3b)Initiate fresh usability analysis as part of a redesign

The key selling point for these changes is the ROI with the practical
elimination of UI testing/bugs on the backend of the program. I'll stress,
you have an audience, take the long view and avoid being short term
disruptive. Lose the battle but win the war on engineering driven UI
design.

Syndicate content Get the feed