And On To Design: Why in this particular sequence? Output Design Input Design Data Design Processing Selection Why in this particular sequence? -determination of requirements -quest for data -cost estimates as system evolves Implementation
Why Look at Output First? (It is the real product) Typical Problems information delay information overload paper domination in reporting excessive distribution non-tailoring of reports
User Interfaces Navigation Mechanism Input Mechanism Output Mechanism how user interacts with the system push buttons, click menu items, type instructions Input Mechanism how the system captures information forms, input screens, card swipes, motions Output Mechanism how the system provides information reports, web pages, feedback screens
Output Design: Initial Questions Audience customers, management, staff, shareholders, government... Format tabular, graphic, summary versus detailed Medium screen, printed, special purpose
Layout Basic format design of the screen or report Consistency is key click on an ‘X’ or ‘-’ Windows/Mac layout common new format emerging for microbrowsing
Usability of a Form Consistency of the Dialog Efficiency Ease Format mnemonics (ctl-S, ctl-X, ctl-V ((?)) ) Efficiency minimum required input where possible Web: drop down menus / first letter select (CAMEROON) Ease self-explanatory, obvious meaning Format consistent between input and display Flexible convenient for the user
Design Principles Sensible layout – consistency Content Awareness – titles, dates Aesthetics – appropriate for the use Level of user experience Navigation consistency Minimize user effort
Designing Outputs Making them useful fulfilling only one use - modularity consistency - similar activities should have similar support web page should be similar for browsers and microbrowsers, allowing for differences in the devices using them This is where MS became the big winner – office was a suite with similar interactions for different applications (word, excel, outlook, powerpoint, access)
Possible Interaction Types Command Language UNIX, Linux Menus Object Based Iconic Natural Language English-like conversational input/output
Use Scenario Much like a Use Case, except several can exist for a single interface a simple narrative of steps of the most commonly occurring transactions browsing making a purchase comparing prices Describes the steps in the process and the interface conversation
Use Scenario Decide what is important Do you agree? the book has an interesting interpretation “Likewise, he thought of several use scenarios that did not lead to sales (e.g. fans looking for information about their favorite artists and music), and he omitted them as well, as they were not important in the design of the Web site.” 4ed p. 339, 5ed p. 351 Do you agree?
Use Scenario User enters his/her postal code, and is asked if they want it remembered User types product search term, then browses through results User selects desired product, adds it to cart User moves to checkout process OR continues shopping
Similar to ‘User Stories’
User Stories What is a User Story? A few sentences in business language that captures what a user does or needs to do as part of his or her interaction with the system. Captures the 'who', 'what' and 'why' of a requirement. limited in detail by what can be hand-written on a small paper notecard.
User Story
User Stories Capturing Requirements Adding Formality Quick way of handling customer requirements without having to create overly formalized requirement documents The intent respond faster and with less overhead to rapidly changing real-world requirements. Adding Formality The informal user stories can be further formalized in use cases.
User Stories Deliberately simple, solve a single function Developed by SME, or in consultation with SME can validate by putting them together and doing a roleplay, or walk through of the process
Front of card The user story – a single function As a user, I can search for a product on eBay Priority: critical Estimate: 4
Back of Card Confirmation Must use a supported browser with Internet connection Not required to log in to search
Interface structure diagram Shows how all screens, forms and reports are related Shows how a user moves from one to another Boxes denote screens, lines show movement from one to another Not strictly hierarchical
Interface structure diagram example
Design Prototyping Storyboards HTML Prototype Language Prototype paper-based mock-ups HTML Prototype for web or custom screen design Language Prototype
Storyboarding
Interface Evaluation Heuristic: checklist Walk-throughs Interaction by users Usability Testing formally audit user interaction
Prototype Evaluation