To practice UCSD Usability Design

Transcription

1 To practice UCSD from principles to process Adds essential UCSD activities and roles to any process. Easy to communicate. Easy to integrate: in organizations and projects. A subset of a development process. Usage example 1

2 Plan the UD process Must also be an integral part of the overall project planning. Process Requirements analysis Elicit business objectives Contextual inquiries System goals, criteria and usability goals User profiles Functional description use -cases Growing software with iterative Bengt G öransson, Redina AB, version 1.8en in Systems Development User Focus Active user involvement Evolutionary development Simple representations Prototyping Evaluate use in context Active user involvement Explicit activities A professional attitude champion Holistic Driven by the er Processes customization A user -centered attitude Usage Scenarios Conceptual Analysis Refine models Interaction Prototypes Analysis Refine models Detailed Evaluation Mock-ups No! Evaluation No! No! Evaluation Goals met? Yes Goals met? Yes Goals met? Yes Deployment Introduce and operate 2

3 Contextual Inquiries and User Profiling Video Focusing on users Video 3

4 Turn requirements into criteria are complementary to usability goals. As we iterate through analysis, and evaluation we learn more about what kind of that will work best. criteria is an aid to for usability. These criteria are derived from user profiles and work tasks, and gives the direction for the (layout and interaction). criteria, an example criteria: Image size. Make the area for images as large as possible. Search area Database Work task bar Minimal user load. Make the handling of the application as easy as possible. No extra load should be put on the user. This includes short access paths to functions and minimized navigation paths within the application. Work oriented. The application should map (support) the actual work situation (work flow) and domain to further minimize the mental load. Support multiple user levels. The same application should allow both novice and expert users to gain maximal usability. There should be no expert mode needed. Box of icons Work space 4

5 criteria: 1. Fast scanning of content. 2. Easy and direct access. 3. Overview. 4. Support the average user. Calendar for overview and navigation criteria, an example Workspace with notepads decisions: No navigation through menus. Supporting criterion 2. Fixed and static layout. Supporting criteria 1, 2 & 3. Clean layout without unnecessary graphical effects. Supporting criterion 1. Focus on content. Supporting criteria 2 & 4. Restricted use of metaphors, use only when appropriate. Supporting criterion 4. Page metaphor for viewing notepads Work task bar Example TOC Customizing the usability process for the project Plan for user participation Overview of the system goals and functionality User profiles and/or personas Contextual task analysis Platform capabilities and constraints goals decisions and criteria Usage scenarios Conceptual Interaction, navigation and information structure Detailed artifacts Feedback and evaluations Doc 5

6 Process Requirements analysis Elicit business objectives Contextual inquiries System goals, criteria and usability goals User profiles Functional description use -cases Growing software with iterative Bengt G öransson, Redina AB, version 1.8en in Systems Development User Focus Active user involvement Evolutionary development Simple representations Prototyping Evaluate use in context Active user involvement Explicit activities A professional attitude champion Holistic Driven by the er Processes customization A user -centered attitude Usage Scenarios Conceptual Analysis Refine models Interaction Prototypes Analysis Refine models Detailed Evaluation Mock-ups No! Evaluation No! No! Evaluation Goals met? Yes Goals met? Yes Goals met? Yes Deployment Introduce and operate Scenarios for describing: Scenarios User stories Current work situation Elicit requirements Future usage PREPARE THE SOLUTION User role: Laboratory staff. Priority: 1 1=must have, 2=should have, 3=could have Context: The user wants to prepare the solution for a particular step in an activity, for example Stock Solution in 1D. The user does not know how to prepare the solution but know in which activity in the System to use it. She wants to find the recipe, make the solution and then use it. Another common situation is that the laboratory staff wants to prepare different solutions in advance. They start with preparing all solutions for a certain activity, and continue with all solution in the next activity. An example is when a 2D Buffer has been started, and laboratory staff is going to make the solutions for staining (i.e. next activity in the workflow). Issues for the prototype: The user starts with searching among all chemicals etc. Criteria may be short name, long name, application field, type of chemical and activity. Information displayed in the result list is the short name. When selecting the name, a view containing information of the solution is displayed. From this view it is now possible to enter information about this specific solution and create bar code for the new item and register it.c 6

7 Conceptual Abstract description of the overall concept. Refined conceptual 7

8 Example of conceptual Main menu bar Drop symbol Navigation Status Workspace Interaction Interaction sequences, information architecture, the dynamics, navigation, menus, etc. Image Archive Thumbnail view Image Archive Open image Options Open Delete Close 8

9 Interaction example of navigation structure Login Avtalstext Registrering Läkemedel Recept Personligt Kontakter Publicera Åsikter Avsluta Hjälp Biverkning Sammanf. Visa Kopia Skicka Erfarenheter Statistik Riktlinjer Info Frågor Fel Åsikt Bekräftelse Dokument Intresse Pers. info Signal Dok. Prefs. Villkor Tipsa arkiv arkiv Om Referens Index Steg-för-steg ATC Interaction structured information architecture Navigation with work task buttons 9

10 Detailed Exact placement, accurate components, colors, fonts, graphics, etc. Detailed grouping information 10

11 User-centered systems, lecture number 15 Prototyping Prototyping going from simple and comprehensible paper sketches to a completed system. User centered systems, spring 2008, Lecture no. 15 Jan Gulliksen and Bengt Göransson, 2008 Prototyping low fidelity User centered systems, spring 2008, Lecture no. 15 Jan Gulliksen and Bengt Göransson,

12 Prototyping high fidelity Prototyping Quick and efficient VB Visual Basic prototype 12

13 Participatory prototyping Drawing area User profiles Personas User User User Drawing material Process Requirements analysis Elicit business objectives Contextual inquiries System goals, criteria and usability goals User profiles Functional description use -cases Growing software with iterative Bengt G öransson, Redina AB, version 1.8en in Systems Development User Focus Active user involvement Evolutionary development Simple representations Prototyping Evaluate use in context Active user involvement Explicit activities A professional attitude champion Holistic Driven by the er Processes customization A user -centered attitude Usage Scenarios Conceptual Analysis Refine models Interaction Prototypes Analysis Refine models Detailed Evaluation Mock-ups No! Evaluation No! No! Evaluation Goals met? Yes Goals met? Yes Goals met? Yes Deployment Introduce and operate 13

14 User-centered systems, lecture number 15 evaluations Preferable in users natural work environment. Powerful when seen as a part of the explorative process of finding (inventing) solutions. It s an interaction between analyzing the problem, seeking solutions to the problem and evaluating solutions. Evaluations as a tool to explore the space and learn more about possible solutions. Possible to combine field studies with evaluations. User centered systems, spring 2008, Lecture no. 15 Jan Gulliksen and Bengt Göransson, 2008 Out in the field, meeting users User centered systems, spring 2008, Lecture no. 15 Jan Gulliksen and Bengt Göransson,

15 User-centered systems, lecture number 15 Evaluation mock-up example User centered systems, spring 2008, Lecture no. 15 Jan Gulliksen and Bengt Göransson, 2008 Evaluation example mock-up and paper Video Doc User centered systems, spring 2008, Lecture no. 15 Jan Gulliksen and Bengt Göransson,

16 Process Requirements analysis Elicit business objectives Contextual inquiries System goals, criteria and usability goals User profiles Functional description use -cases Growing software with iterative Bengt G öransson, Redina AB, version 1.8en in Systems Development User Focus Active user involvement Evolutionary development Simple representations Prototyping Evaluate use in context Active user involvement Explicit activities A professional attitude champion Holistic Driven by the er Processes customization A user -centered attitude Usage Scenarios Conceptual Analysis Refine models Interaction Prototypes Analysis Refine models Detailed Evaluation Mock-ups No! Evaluation No! No! Evaluation Goals met? Yes Goals met? Yes Goals met? Yes Deployment Introduce and operate To deploy and introduce a system Critical to the success of the system. Usually gets too little attention. Must start when the project starts. Involves: organization, work processes, work force competence, etc. The system owners must be involved from the start of the project. Education and support. Use ambassador users. 16

17 UCSD and the Rational Unified Process The RUP statement The Rational Unified Process or RUP product is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget. Rational Unified Process v

18 Architecture-centric and use-case driven Use cases drive the Rational Unified process end-to-end over the whole lifecycle, but the activities are centered around the notion of architecture - system architecture, or for software-intensive systems, software architecture. The main focus of the early iterations of the process - mostly in the elaboration phase - is to produce and validate a software architecture, which in the initial development cycle takes the form of an executable architectural prototype that gradually evolves to become the final system in later iterations. Rational Unified Process, version Rational Unified Process Best practices 1. Develop iteratively. 2. Manage requirements. 3. Use component architectures. 4. Model visually (UML). 5. Continuously verify quality. 6. Manage change. 18

19 Process Structure : The Basic Elements of RUP UCSD in RUP Scattered in the process 19

20 UCSD in RUP Requirements: Analysis & : Deployment: Conceptual Road Map: Engineering Concepts: User-Centered, Testing lines: Role playing, Interviews, Storyboarding, User Interface etc Use Cases Ux Plug-In Use-cases and UCSD Too often there is no distinction between the description of the current work situation and the requirements on the new system. Users are experts in their profession (work), not in systems development. Use-cases do often continue presumptions and preconceived notion about the of the user interface. Use-cases are sequential by nature. Does often lead to a sequential user interface an interaction structure, not supporting a flexible and effective dialog. The user interface becomes fragmented : one use-case = one window. No single and agreed upon definition. 20

21 Use-cases and UCSD continued Use-cases are difficult for users to perceive and imagine as the future work situation. Is not enough to communicate with users. Different requirements on the size of the use-cases. Software developers prefer small use-cases when specifying the functionality. For usability ers use cases instead have to be large to correspond to users work tasks. The way use-cases are described can have implications on the space. Use-cases are modeled with the software system as the focus of attention. Users must take an active in the use-case modeling and use other ways of communicate in parallel. UCSD in RUP summarizing This could be improved... is distributed and vaguely defined often not a major concern and simply disappears. RUP is architecture-centric and not user-centered. In general, too much on artifacts. There is a risk that the big picture gets lost and that each role puts too much effort in writing documents (fill out forms). No one is coordinating or is in charge and responsible for the usability. No support for usability. This is ok! Use-cases can be user-centered. Focus on requirements. Iterative development. Multidisciplinary teams. 21

22 discipline RUP A plug-in to RUP: textual and graphical guidelines, examples and templates. Adds the key principles for user-centered systems to Best Practices segment in RUP. Contains accepted and usability methods. The news is that they are put into a software engineering framework (RUP) and that they go beyond usability testing and usability goal setting / requirements. User-centered systems throughout the systems life cycle. RUP will never be fully user-centered, but it can be improved. Benefits of the discipline The discipline is visible and easy to adopt. UCSD integrated, or at least visible, in the software engineering process. Contributes support for focusing on users and active user participation. Adds roles with explicit usability, UCSD and HCI competence. Quality assurance for usability. Early, active and continues involvement of users and business will make the introduction and deployment of the system easier and more successful. 22

23 in RUP : Overview Plan a user -centered approach [ Inception and early elaboration ] Perform competitor analysis Conduct user studies [ Late elaboration and construction ] Conceptual Interaction Detailed Develop user assistance Monitor usability work evaluation 23

24 [ Inception and early elaboration ] [ Inception and early elaboration ] [ Late elaboration and construction ] [ Late elaboration and construction ] User-centered systems, lecture number 15 Workflow detail: Conduct user studies Plan a user -centered approach Perform Conduct competitor analysis user studies Conceptual Interaction Detailed Develop user Monitor assistance usability work Vision (modified) User profiles (rich description) Usage scenarios Usage and task model (current & future) goals & criteria Supplementary specifications (modified) evaluation Domain experts End user Other stakeholders Field study specialist User profiling Analyze context of use and work environment Usage and task analysis Explore future use Obstacles and enhancements (business and work process improvements) sketches (explorative) Business use - case model (modified) Domain model (modified) Business use-case (modified) Use case model (modified if existing) Business Vision Context of use and work environment Glossary (modified) Workflow detail: Interaction Plan a user -centered approach Perform Conduct competitor analysis user studies Conceptual Interaction Detailed Develop user Monitor assistance usability work Interaction model (navigation map) Interaction prototypes (storyboards) Interaction description evaluation Domain experts End user Interaction er Develop prototypes Develop navigation structure Develop information architecture Content and layout guidelines and rationales (modified) Domain model (modified) Use case model (modified) 24

25 [ Inception and early elaboration ] [ Inception and early elaboration ] [ Late elaboration and construction ] [ Late elaboration and construction ] User-centered systems, lecture number 15 Workflow detail: Develop user assistance Plan a user -centered approach Perform Conduct competitor analysis user studies Glossary (modified) guidelines and rationales (modified) Conceptual Interaction Detailed Develop user Monitor assistance usability work evaluation Domain experts er Integrate assistance in system Plan user assistance Recommendations for work and business improvements End user Course developer Develop training material Training and support plan Training and support materials Technical writer Develop support material Workflow detail: evaluation Plan a user -centered approach Perform Conduct competitor analysis user studies evaluation plan problems and re- recommendations Conceptual Interaction Detailed Develop user Monitor assistance usability work evaluation Domain experts Plan and conduct evaluation End user evaluation specialist Determine usability metrics Customer Recruit representative users Change request (modified) Test plan (modified) Iteration plan (modified) 25

26 Roles Interaction er User-interface er Field study specialist er evaluation specialist End user Domain expert Graphic er Technical writer Course developer Technical reviewer Case: Volvo IT Adjusted the plug-in to their development case of the RUP. 2-day workshop with a team from Volvo IT. Used by Volvo IT in a large project at the Volvo Group Inc. Will be re-fined and finished by them. Implemented world-wide. Using ambassadors. (Volvo IT does not use the Business Modeling (BM) discipline) 26

27 The Volvo IT customization New names ( &, Architect) Fewer artifacts Altered roles Close cooperation between & and Requirements Brief descriptions added Example from Volvo IT E.g. elaborated on the Develop User Assistance activity 27

28 Experiences using the discipline Helps out to keep user focus usability on the agenda. Makes user-centered activities explicit and easy to communicate. Straight forward, easy to apply. Used by others and ourselves. Practiced within our consultant company, but we have to adapt to our customers wishes situated UCSD. 28