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

Re: [agile-usability] Re: incremental design -vs- overall user experience

Expand Messages
  • William Pietri
    Hello, everyone. Thanks for setting this up, Jeff! ... Your point is well taken, but I think you re selling APIs a little short. APIs, after all, are
    Message 1 of 38 , Jul 14, 2004
      Hello, everyone. Thanks for setting this up, Jeff!

      On Wed, 2004-07-14 at 09:23, Brian O'Byrne wrote:
      > I don't agree that the interaction design concern has to go
      > _everywhere_. On the second of the two projects I mentioned there was
      > a real n-tiered architecture and were very definitely two teams, one
      > for the problem domain and one for the UI.
      > The PD team followed a very traditional methodology and wrote service
      > code that could be used by many different UIs. They concerned
      > themselves with the business model, persistence and most of the
      > technology, exposing APIs for the UI team to use.

      Your point is well taken, but I think you're selling APIs a little
      short. APIs, after all, are interfaces for programmers. When I'm
      building an API, I ask myself a lot of the same questions that I do when
      building a more traditional UI. Who will be using it? What are they
      trying to accomplish? How can I make common things easy? How can I make
      dangerous things hard?

      This is most important when you're building APIs for broad use, of
      course. EBay and Amazon have APIs used by thousands; Microsoft and Sun
      sell APIs used by millions. For these, it's obvious that investment in
      usability pays off. But even intra-company, inter-team APIs are worth
      effort to make them usable. I've seen companies where internal APIs with
      no thought of programmer usability cost tens or hundreds of thousands of
      dollars in wasted effort on other teams.

      So I'd agree that a team building internal code need not be particularly
      skilled in building GUIs. But I do think they should be relentless in
      focusing on the usability of their creations, always keeping in mind
      their users and, by proxy, the real users that the system is being built

    • katharina9267
      Larry, This is without a doubt an issue that I came across in my experience as a usability manager. Do you suggest that this work should be done in iteration 0
      Message 38 of 38 , May 30, 2007

        This is without a doubt an issue that I came across in my experience
        as a usability manager.

        Do you suggest that this work should be done in iteration 0 using the
        agile methodology? This seems to be increasingly a recommendation in
        a number of white papers and publications such as Scott Ambler.
        However, when you say 'minimal effort' how does this translate into
        time scales - is there an average that you work with in your
        experience let's say 1-2 weeks?

        I also appreciate, if you could forward the pdfs on the collaborative
        UI review method that you mentioned in a previous message.
        Many thanks,

        --- In agile-usability@yahoogroups.com, "Larry Constantine"
        <lconstantine@...> wrote:
        > Jeff,
        > An effective way around this problem is to draft a navigation
        > (screen flow) in advance based on provisional understanding of user
        > and tasks in the application. This architecture gives a reasonably
        > thought out framework on which to hang the features and functions
        as they
        > arise "organically." The navigation architecture is itself reviewed
        > refactored as needed as the details of the application emerge. This
        > is what I describe as "architecture-first development" in the new
        > Report on agility and usability. It's proven to be a good
        compromise that
        > yields maximal payoff in maintaining a sound UI organization with
        > minimal upfront investment.
        > --Larry Constantine
        > Chief Scientist | Constantine & Lockwood, Ltd.
        > -----Original Message-----
        > From: Jeff Grigg [mailto:jeffgrigg@...]
        > Sent: Tuesday, 13 July 2004 7:48 PM
        > To: agile-usability@yahoogroups.com
        > Subject: [agile-usability] incremental design -vs- overall user
        > I can't claim to be an expert on user interface design or agile
        > methods, but here's a thought that's been bothering me for a while:
        > It's been my experience that systems that "grow organically" over
        > time often have bad user interfaces. New features are often buried
        > deep within the existing user interface structure, making it hard
        > find. New reports, for example, are added as buttons or menu
        > options deep in the work flow, where they're first needed, but
        > made available from higher level menus.
        > I've found that drawing screen flow diagrams of the overall system
        > illustrates these problems and guides redesign of the GUI to make
        > the system more usable.
        > But...
        > How can one avoid this problem in "organically growing" systems?
        > Does the "overall user experience" need to be planned up-front,
        > when functionality is implemented incrementally?
        > As project direction changes during implementation, what triggers
        > you to recognize that the user interface flow needs to be
        > to most effectively support the new business requirements you've
        > discovered?
        > Yahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.