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

[usage-centered] Rapid Prototyping

Expand Messages
  • Larry Constantine
    Chris, I am sorry your message remained unanswered so long, but it seems that everyone on the list is either overwhelmed (like me) or on vacation (like I wish
    Message 1 of 3 , Aug 1, 1999
    • 0 Attachment
      Chris,

      I am sorry your message remained unanswered so long, but it seems that
      everyone on the list is either overwhelmed (like me) or on vacation (like I
      wish I was).

      >We have no users, no product ideas to start with.


      If you have a GUI in your prototypes, you have users, even if they exist
      only as fantasies in your minds. That, in all cases, should be your
      starting point in usage-centered design--you think something based on some
      technology will be useful to somebody. To reverse the inside-out approach
      to become an outside-in, usage-centered approach, I think you need to spend
      more time thinking about who these fantasied potential users are, the roles
      they play, and their needs.

      >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?

      How long it takes to model user roles, user tasks, and interface contents
      depends entirely on hohe problem is and to what level of detail/precision
      you need to go. We have often completed the role modeling for fairly
      complex applications in a few well-spent hours. A design team we worked
      with recently completed visual and interaction designs for 19 of 34 core
      views in a very complex application in a week--in the process generating
      several patentable innovations, I might add. Of course, the detailed final
      design took longer, but for prototyping rather than production purposes,
      programming could go directly from sketches and notes to code.

      >Our mission is to brainstorm, design, and build prototypes that represent
      potentially useful systems.

      >We have only a few starting points in the technologies that my company
      owns

      >Is this an effective way to improve the number of practically useful
      >prototypes produced by our methods?

      As a consultant on both the business and technology sides of design, my
      first response is to wonder about a business model that is based on
      generating large numbers of solutions looking for a problem. There more be
      more efficient ways to exploit your company's technology and human
      resources.

      --Larry Constantine
      Director of Research & Development, Constantine & Lockwood, Ltd.
    • Chris Lichti
      Hi Larry, Here are some snippets from your message for context... ... I see where you are coming from in your concern over our team s business model, but as
      Message 2 of 3 , Aug 1, 1999
      • 0 Attachment
        Hi Larry,

        Here are some snippets from your message for context...
        ...
        >to become an outside-in, usage-centered approach, I think you need to spend
        >more time thinking about who these fantasied potential users are, the roles
        >they play, and their needs.
        ...
        >How long it takes to model user roles, user tasks, and interface contents
        >depends entirely on hohe problem is and to what level of detail/precision
        >you need to go.
        ...
        >Of course, the detailed final
        >design took longer, but for prototyping rather than production purposes,
        >programming could go directly from sketches and notes to code.
        ...
        >As a consultant on both the business and technology sides of design, my
        >first response is to wonder about a business model that is based on
        >generating large numbers of solutions looking for a problem. There more be
        >more efficient ways to exploit your company's technology and human
        >resources.

        I see where you are coming from in your concern over our team's business
        model, but as backwards as it seems, it appears to be accomplishing our
        goal, which is to inspire the rest of the company to create new products
        targeted at real customers by seeing new technologies and new ways to use
        existing technologies.

        This would not work if we ignored the concerns of real customers, but our
        definition of a customer is not established by a marketing team. We get to
        target whoever we want.

        This also wouldn't work if we did not maintain a rigorous schedule of at
        least one new fully-functional prototype release every month. We could not
        maintain this schedule if we were not given ultimate flexibility in
        choosing languages, tools, environments, and platforms to use in our work.

        We have exactly two people (myself included) working on speculative rapid
        prototyping. The technology and human resources used for this effort,
        while not negligible, have still been relatively small. Our work has
        inspired development teams in both our local company and our parent company
        in Japan to create products based partially on our working prototypes. As
        a member of the team, I am hardly impartial, but I believe we actively and
        significantly contribute to the bottom-line of our company. I'm willing to
        accept the possibility that we've just been a waste of resources, but I
        hope that's not the case.

        In any case, my concern with usage-centered design is in learning how it
        may or may not help make our prototypes easier to develop, easier to
        understand (more effective), or both. We have our own methods for writing
        "sketches and notes" that has done okay so far. But I'm always looking for
        better, faster, easier ways of doing things, and I wonder if some form of
        usage-centered design might fit the bill.

        Perhaps we could use it to break down some of the larger prototype concepts
        before implementing them, in an effort to make the engine and the UI
        reflect the distinct usages, rather than distinct underlying technologies...

        I'm beginning to suspect that a boiled-down version of usage-centered
        design is what I'm after, but I'd like to hear your thoughts. I'm open to
        the possibility that I'm way of track, so feel free to trample my
        non-existant ego in this field. :-)

        Thanks,

        Chris


        ---------------------------------------------------------------------
        Christopher C. Lichti
        Research Systems Consultant
        chlichti@...
        Public PGP Key available from the key server at http://pgpkeys.mit.edu:11371
        ---------------------------------------------------------------------
      • Larry Constantine
        Chris, ... And now I have a clearer idea of where you are coming from. I hope you understand that I was not questioning your methods or contribution to the
        Message 3 of 3 , Aug 1, 1999
        • 0 Attachment
          Chris,

          >I'm beginning to suspect that a boiled-down version of usage-centered
          >design is what I'm after, but I'd like to hear your thoughts. I'm open to
          >the possibility that I'm way of track, so feel free to trample my
          >non-existant ego in this field. :-)

          And now I have a clearer idea of where you are coming from. I hope you
          understand that I was not questioning your methods or contribution to the
          company, more just raising the question of alternative ways to use
          resources. Obviously, from what you described, the "speculative
          prototyping" approach is working for you.

          >In any case, my concern with usage-centered design is in learning how it
          >may or may not help make our prototypes easier to develop, easier to
          >understand (more effective), or both.

          Given how you framed the problem, I think you are absolutely right about a
          streamlined process. We consider the essential use case model (essential
          narratives plus use case map) the last stand fall-back position in
          extremely time-pressured or information-poor contexts. In your position, I
          would experiment with a use case brainstorming, then narrative writing step
          in your process. My focus on the fantasized user roles in the previous
          message has to do with our experience in trying to do use case modeling in
          the absence oif a good user role model. It is darned hard and takes a lot
          of practice to do reasonably well. We only skip the user role model when
          there is a gun to our heads. But, give it a try and maybe share your
          experiences with the rest of us.


          --Larry Constantine
          Constantine & Lockwood, Ltd.
        Your message has been successfully submitted and would be delivered to recipients shortly.