C SC 225 Lecture 15: User Interface Design : Processes

[ previous | schedule | first ]

Source: Designing from both sides of the screen, by Ellen Isaacs and Alan Walendowski, New Riders Publishing, 2002, www.uidesigns.com.

Overview

• User Interface Design is not covered in either of our course textbooks
• I will present highlights from Designing from both sides of the screen
  • Its subtitle : "How Designers and Engineers Can Collaborate to Build Cooperative Technology"
  • Ellen Isaacs is an Interaction Designer (in front of the screen)
  • Alan Walendowski is a Software Engineer (behind the screen)
  • Website is www.uidesigns.com

User Interface Design Processes

• Part 2 of the book is called The Process. It comprises seven chapters
  • Setting Up: Understanding Users' Needs
  • Structuring the User Interface
  • Laying Out the User Interface
  • Architecting with the UI in Mind
  • Initial Development
  • Iterative Development: Observing Use
  • Conclusion
• Today's class features highlights from this part of the book
• This design process supports the user interface design goals of previous lecture
• This is a user-centered design process whose cornerstones are:
  • Understand user needs, so your software will meet "real, observed needs”.
  • Design the UI first, then develop software architecture around it.
  • Iterate, to get user feedback throughout the development process (think XP and Agile)
  • Use it yourself, especially early in development, to discover obvious shortfalls
  • Observe others using it, beginning when core functionality is working (about halfway through), through usability testing and/or usage studies.

User Interface Design Steps

• This is intended to be a summary checklist. It does not contain all the information needed to adequately complete the steps. Refer to Isaac/Walendowski book.
• Phase 1: Understand Users' Needs
  1. Spend time observing people doing the activity you are going to support, talk to them, and record your observations. Also study similar apps if you can.
  2. Come up with task list. From these you can develop usage scenarios, a.k.a. use cases. Each is a textual description of the activities required to accomplish a given task.
  3. Next develop functional requirements list from task list. The things the system needs to provide to support user tasks. It is important to develop a map (correspondence) of tasks to requirements.
  4. Organize functional requirements into priority categories. Authors define three: core, important, nice to have.
• Phase 2: Structure the User Interface
  5. Trace the functional requirements back to associated tasks to produce a Prioritized Task List. If you developed the map in step 3, this is trivial.
  6. Classify each task into one of four categories of task usage, prioritized as follows:
     • used frequently by many
     • used occasionally by many
     • used frequently by few
     • used occasionally by few.
  7. Reorganize task list by each items category, retaining priority level.
  8. Determine what constitutes Display Units for your application. This could be windows, or screens, or pages, or something else appropriate for your platform.
  9. Assign functional requirements to Display Units (hereafter called “screens”).
     • Consider each task according to visibility and click guidelines (the higher the priority of a task, the greater visibility and fewer clicks it gets)
     • Assign a task's functional requirements to screens accordingly.
  10. Main screen is most visible. Highest visibility tasks get screen space, secondary get menu item.
  11. Generate Task Flow Diagram showing how the screens relate to each other. Each screen represented by a labeled box. Boxes are connected by arrows representing the control flow that occurs while carrying out a task.
• Phase 3: Lay Out the User Interface
  12. Develop UI mock-up on paper. There are a dizzying number of guides to support this activity. UI can be hand drawn. You can later use a UI prototyping tool. Authors used Photoshop. You could use Visual Studio.
  13. Walk through the tasks. Simulate the step-by-step performance of each task on the task list, using the paper mock-up UI. Revise as necessary to clarify and streamline tasks used frequent by many. Repeat the walk through until satisfied.
  14. Write the formal UI Specification. Authors do not prescribe a specific format. It should describe both the look and behavior of the UI.
• When should these phases be performed?
• Much of the work in these three phases should be completed even before software architecture design decisions are made.
• All of these steps should be done before implementation begins.
• Completion does not mean the UI is finalized; it will be revised throughout implementation and testing.
• The UI Spec should be updated to reflect revisions.
• Isaac/Walendowski provide an example UI Specification for an instant messaging application called Hubbub at www.uidesigns.com/spec/
• Hubbub is a real application! Learn more about it at www.hubbubme.com

System Design, Implementation, and Testing

• Once the UI design phases above are mostly completed, turn to system design itself
• Phase 4: Software Architecture
  • High level architecture designs should be based on UI considerations.
  • Example: For a networked app, should it be client-server or peer-to-peer? What protocols?
  • Does it need to support or be implemented on multiple platforms?
  • Produce a System Architecture document
  • Produce a feature list based on the architecture and UI Spec
  • Develop preliminary schedule based on architecture and feature list
• Phase 5: Initial Development
  • Implement the features “as they were designed”.
  • Implement “core” features, start to use the system yourself and make adjustments, then let other people (e.g. clients) start using it.
  • Once you start getting usage feedback, the core features shift into next phase while you do initial development of “important” (second priority) features.
  • Trade-offs become evident at this point and need to be negotiated between designer and engineer. E.g. implementation cost of a feature may be higher than is justified by its design priority.
  • Collaboration by designer and engineer is critical in this phase
• Phase 6: Iterative Development
  • All players are involved: users, designers, engineers
  • Usability Testing and Usage Studies come to the fore
  • Usability Testing is widely-used and reasonably formal
  • select small representative user group
  • person is in lab setting with “observer”
  • person is given task to accomplish, and “thinks aloud” while doing so
  • actions are recorded in one or more ways
    • videotape
    • input device tracking
    • observer writing notes beside user
    • observer watching through one-way mirror or camera-monitor
  • Collect both qualitative (e.g. note where confusion and mistakes occur) and quantitative data (e.g. time and effort to complete task)
  • Data are analyzed by usability expert, who makes recommendations
  • ADV: Great for discovering major problems and benchmarking
  • DIS: testing limited to assigned tasks, occurs in artificial setting, better for testing occasional rather than frequently performed tasks, better for evaluating “learnability” than “usability”
  • Usage Studies are less well-known and less formal
  • Akin to internal alpha testing
  • Can begin early in implementation
  • Focus is more on system usability than functionality
  • Should be realistic setting and representative users
  • Results of study are applied in next iteration