1. Designing a System 4 October 2006

2. Beyond the Technology What will be implemented – external view –“glossy” brochure –Use cases and user types Translation to a software design –Web interface –Data objects –STRUTS diagram –Domain model and interface How it will be implemented –Project plan: when and who

3. Design Phase Concept User Types Use Cases

4. Marketing What are you going to accomplish? What problem are you solving? –How is it currently done? –How are you going to do it better? NO TECHNICAL DETAIL Last year’s examples –CampaignScaperCampaignScaper –HeelBidHeelBid

5. Design Phase Concept User Types Use Cases

6. How Do You Describe a User As a Person –Knowledge and experience –Age and gender –Physical handicaps –Characteristics of tasks and jobs –Psychological characteristics By his or her role in the system –Functions –Privileges

7. Methodologies For this project –Three or four sentences describing your assumptions about the user type and their role in your system For more complex systems –Personas

8. User Requirements - Persona A description of a fictitious user representing a distinct user group –User groups are based on unique goals, from the goal model –Each persona represents a unique set of goals for design Personas help direct the design –Allow designers to focus on people’s needs and differences –Skills, motivations, emotions, behaviors –Design teams often post photos and descriptions in their work areas –Use each persona as though it were a real person –“What would Jackie do if …”

9. Persona excerpt from hotel reservation system

10. Story excerpt

11. Design Phase Concept User Types Use Cases

12. A statement of the functionality users expect and need, organized by functional units  Functional units to be designed  Creation, removal, update, purchase, browse, … Relationships between user roles and use cases  User activities, decisions, and objects involved  Measures and targets that satisfy task- level success criteria

13. Methodologies For this project –Text definitions –Examples from last year CampaignScaper HeelBid For more complex systems –UML

14. Sample Use Case: UML notation Use cases are often inter-related extend is an optional association include is a mandatory association Each use case is a logical function to be designed The collection of all use cases defines the system Use Case

15. Into Development Mode Interface Design – Building a Web Site Building a System Dividing the Work Managing the Process

16. About Site Design (from Yale site guidelines) In architecture as in all other operative arts, the end must direct the operation. — Sir Henry Wotton, The Elements of Architecture Although people will notice the graphic design of your Web pages right away, the overall organization of the site will have the greatest impact on their experience. The fundamental organizing principle in Web site design is meeting users' needs. Ask yourself what your audience wants, and center your site design on their needs.

17. The UI Iceberg Visuals InteractionTechniques Object Model Feel 30% Look 10% The things you use 60% Toolkits and Style Guides help with look and feel, the tip of the usability iceberg. Real usability gains come from system and application objects perceived by users.

18. Principles of Good Screen Design (Galitz) Consistency Starting in the upper left corner Simple navigation Hierarchy for importance Pleasing visuals Captions

19. Development Overview Discovery Design Implementation Users Check in Greet Register Create key Confirm room Check reservations Task Analysis Dialog Window Container Implementor's Model Model of Users’ Objects Hotel Guest Reservation

20. Domain Classes Object-oriented paradigm, not implementation Domain = application specific Classes defined in natural language –Used to explain the architecture and design Classes derived from the requirements –Need not match the implementation –Likely design in small project

21. Defining Domain Classes Begin with Use Cases Identify nouns –External agents are not domain classes –Are these key classes for the application? –Are there others? Identify attributes and functionality for each class Validate –Walkthrough use cases –Try changes and extensions Look for –Missing attributes or functions –Changes that reach everywhere

22. Into Development Mode Interface Design – Building a Web Site Building a System Dividing the Work Managing the Process

23. With Teams of Two Pair Programming –High quality –No coordination problems –Need to coordinate work times Vertical Towers –Both people get full experience –Both people need to learn all parts –Parts may be inconsistent –May not find all reusable components Horizontal Slices –Each person only needs to become expert in parts –Do not get the work in both parts –Need to assure pieces work together

24. Pair Programming Two people working at a single computer Built-in backup and inspections Collaboration builds better code Different models: mechanics –One drives, the other talks –Keyboard slides between the two Different models: logical –One tactical, the other strategic –Both think about the full spectrum but bring different perspectives

25. Into Development Mode Interface Design – Building a Web Site Dividing the Work Managing the Process

26. Technical Risks New features New technology Developer learning curve Changes that may affect old code Dependencies Complexity Bug history Late changes Rushed work Tired programmers Slipped in “pet” features Unbudgeted items

27. Knowing How You’re Doing If you don’t have a plan, you don’t know if you’re on schedule Weekly checkpoints If you’re behind? –Work harder –Adapt assignments –Reduce scope