[Sigia-l] Edward Tufte

[Smith, Denise (Hewitt)]

<snippity-snip Jon's response>

> > The first was his overt trashing of user
> > testing (he sd that good designs mean you don't
> > HAVE to user test).

Of course good designs mean you don't have to test.
Unfortunately testing is the only way you know you have a good design...

<end snip>

I think its a matter of WHEN you test. We test before the design stage as a
part of our requirements gathering. Its been really vital for us to find out
what's already working in a design - not throwing the baby out with the
bathwater, and all. Users often seem to resent redesigns, esp when the site
was already decent, so maintaining some familiarity can be a good thing
(depending!!). In addition, we test to find out what user's needs ARENT
being met - I have had some fabulous comments made during task-driven
testing (like: "there's no search box on the whole site!" when it was only
missing from the home page. There was a link marked search, but everyone was
looking for the text-input box!). Good stuff like that. Only way to really
know is to test with real users.

That being said, I agree with Krug that a LITTLE testing with a few users is
also better than none at all... and I know there wont always be budget or
time for it. Heck, i designed an entire site for using only the "page
headers" given to me in Excel, because I was not "allowed" to see the
content (legal reasons due to a merger). 

Anyhow, I guess what I am saying is - any time I have tested before I
actually finished my requirements gathering phase, I *know* I have built a
much better design than I would have otherwise. 

Thoughts?

Thanks!

Denise