Re: Product First?

["Chuck Martin" <twriter -at- sonic -dot- net>]

"Andrew Plato" <intrepid_es -at- yahoo -dot- com> wrote in message
news:113477 -at- techwr-l -dot-  -dot-  -dot- 
>
> Chuck had a interesting point from the "Is the job market that bad"
> thread.
>
> I wrote...
> > > But, we have good tech writing jobs as well.
> > > However, I will say that the
> > > tone of clients has changed. The days of long projects where we could
> > > design templates and discuss user readability are very much gone. Our
> > > projects are either long-term outsourcing arrangements
> > > or "quick n' dirty,
> > > get the docs done and leave" contracts.
>

> "Chuck Martin" wrote...
> > This would concern me because it smacks of a "product first" attitude
> > among companies rather than a "user first" attitude--and not just for
> > the docs. Time and time again, it has been shown that better products
> > almost always do better in the long term than first-to-market products.
> > (DON'T bring up beta vs. VHS.) Yet despite this evidence, companies push
> > unusable products out the door to beat the competitors that are left. Oh
>
> > yeah, and the docs are tacked on as an afterthought.
>
> I don't agree. Companies could spend 98 years figuring out what users want
> and never hit the mark. Honestly, most users are stupid as rocks and don't
> know what they want. You have figure it out for them. Hence, documentation
> must educate them and show them why your products are great and can be
> useful.

I can['t agree with this. Users are *not* stupid. On the contrary, most
users are quite smart--at what they do, which oftentimes isn't what we're
documenting (or designing). But bad design (and bad documentation)
contribute to making users *feel* stupid when learing about new things,
especially things such as computers and software that are touted--loudly--to
make users' lives easier.

Users do indeed know what they want. But the popular and easy methods for
discovering that, such as surveys and focus groups, don't work for several
reasons. First, users often will say what they think they do, rather than
what they actually do. Second, they may also say what they believe the
surveyors want to hear, rather than reality. And third, especially in a
focus group environment, there is groupthink at work, where even if a user
disagrees with the group opinion, they are less likely to voice that for
fear of embarrassment or shame.

That's not to say that education can't help users reach their goals. But
good product design has the advantage of both providing the users with what
they need to know as an inherent part of the design and reducing the need of
users to reference separate documentation.

Companies don't need 98 years to figure out what users want. The metrics and
procedures to do this are well documented. But these procedures aren't seen
as making active progress toward a product goal (in the same way as, for
example, production of lines of code), so they aren't done. Companies are
left, then, with guesswork and assumptions, which often turn out to be wrong
when the product is finally released and the tech support lines are
overwhelmed with calls about how to performs basic tasks. This results in
the attitude of the users being seen as stupid. Then, the company sees this
as a potential profit center, starts charging for tech support calls, and
thus reducing incentive to improve the product design (fewer tech support
calls mean less income).

>
> Truth be told, some of the most un-usable crap in the world is
> tremendously popular and making people billions while highly usable,
> stable, decent stuff is languishing on shelves. History is equally filled
> with stories of "user-first" products that were massive failures.
>
> I think the real answer is "market first."  A product must fill a need in
> a market and it must fill that need well.  Good documentation can show
> readers why said product is useful and fills their needs. This will add to
> a product's ability to excel in the market.

One problem here: time and time again, users don't read documentation. I
have seen studies that show this. Users will frequently try many
things--trial and error, calling a friend, caling tech support, and so
on--before they will read the docs. When users behave like this, the best
documentation in the world is useless. And bad design creates frustration
among the users and hinders them from reaching their goals.

>
> From my perspective, clients want docs, they want them fast, and they want
> them to show readers how to make the most of the products. Yes, sometimes,
> those products are stupid or poorly designed. But, its not my job to
> re-engineer the UI. I might make suggestions to improve it, but if the
> client wants it that way, then it stays that way. I have to adapt the docs
> to fit reality, not what I WANT the products to be.
>

But the bottom line isn't how *you* want the products to be (any more than
it is the way *I* want the products to be. Even design experts will suggest
ideas, then claim that the ideas shoudln't be implemented until they are
thoroughly tested with real users of the target market(s). The *only* right
answer to the question of whether or not a design is good or not is with the
end user. Anyone else's input does nothing more than contribute to global
warming. The users' success (or lack therof) in reaching their goals with
the product is *the* indicator of the quality of the design.

Yes, users do reach their goals with badly designed products. But I'd
venture to say that they do not do so easily and without frustration.

Just for example (here comes the next firestorm), Jakob Neilsen's recent
AlertBox (http://useit.com/alertbox/20010708.html) describes some testing of
web sites where users were trying to find physical locations of companies.
Users succeeded 63% of the time. As Neilsen says; "...a success rate of 63%
implies a failure rate of 37%. That's a lot of customers to lose because
they can't find your store, office, or dealership."

Scary.


--
--
"I don't entirely understand it but it is true: Highly skilled
carpenters don't get insulted when told they are not architects,
but highly skilled programmers do get insulted when told
they are not UI designers."
     - anonymous programmer quoted in "GUI Bloopers"

Chuck Martin
User Assistance & Experience Engineer
twriter "at" sonic "dot" net      www.writeforyou.com



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com

TECH*COMM 2001 Conference, July 15-18 in Washington, DC
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com


---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.