Loading ...
Sorry, an error occurred while loading the content.

[usage-centered] Introduction to Usage-Centered

Expand Messages
  • Chris Lichti
    Hello, My name is Chris Lichti. I m a Systems Designer working for the research department of Claritech Corporation. My team (two people, really) is
    Message 1 of 1 , Jun 24, 1999
    • 0 Attachment

      My name is Chris Lichti. I'm a Systems Designer working for the research
      department of Claritech Corporation. My team (two people, really) is
      responsible for rapid prototyping. We conceive of, design, and implement
      fully-functional prototypes about every month. We have no limitations on
      tools, languages, components, or distribution, so we can afford to take
      every shortcut possible to achieve a fully-functional system that shows
      engine and user interface working, if not bug-free, at least well enough to
      do demos and user studies.

      Using our rapid prototyping methods, we have been able to implement, for
      example, a system that operates on RDB and free-text data using a CAD
      interface for designing networks of operations that have data flow through
      the operations over heterogeneous data to provide analysis and, ultimately,
      decision support in real-time. That particular project took 3 weeks.
      There are plenty of others, but the reason I'm bringing this up is not to
      toot our own horn, but to show you where I'm coming from as I proceed to
      implore you for help.

      I came to the CHI SIG meeting and ultimately asked to be on this list
      because I believe that my work is fundamentally flawed. Our mission is to
      brainstorm, design, and build prototypes that represent potentially useful
      systems. The more I learn about usage-centered design and other design
      methods, the more I've come to realize that we are shooting blindly in the

      We have ideas about usage, of course. Our prototypes reflect uses that we
      think might be useful to the ambiguous concept of a "user" we have to work
      with, but we spend very little time thinking about the uses, and a lot of
      time thinking about designing revolutionary GUIs. I'm beginning to think
      that this is backwards.

      Of course, we cannot simply adopt the methods of a standard practitioner.
      We have no users, no product ideas to start with. We have only a few
      starting points in the technologies that my company owns, and even then,
      those technologies are very general-purpose.

      We must supply our own usages for each system. Until now, we have gone
      straight from brainstorming (x hours) to system designing (x hours) to
      implementing (x days). Perhaps we would be more effective if we added
      another step. Something like:

      Brainstorm (hours)
      Usage-centered design (hours)
      System design (hours)
      Implementation (days)

      Does anyone here think this is practical, given current methods and goals?
      Can usage-centered design effectively occur in a matter of hours, at most a
      day? Is this an effective way to improve the number of practically useful
      prototypes produced by our methods?

      I wish I could ask fewer questions and contribute more, but I feel somewhat
      out of my element here. Perhaps this is not the right forum for my

      In any case, I'm grateful for any help you folks can offer.



      Christopher C. Lichti
      Research Systems Consultant
      Public PGP Key available from the key server at http://pgpkeys.mit.edu:11371


      eGroups.com home: http://www.egroups.com/group/usage-centered
      http://www.egroups.com - Simplifying group communications
    Your message has been successfully submitted and would be delivered to recipients shortly.