1. BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting June 16, 2011 06-2011 Solution Architecture: UX Design Synthesizing User Requirements into User Interfaces

2. Designing the User Experience At some point, preferably BEFORE developers begin writing code, someone has taken the time to architect the solution from a User Experience standpoint. The UI is the vehicle through which the users experience the fulfillment of their requirements. UI Mocks paint a picture of the vehicle that you think will answer all (or most) of the users’ needs. Mom User Requirements Room for 20 bags groceries Ability to install/remove 2 car seats Ability to get from home – grocery store Ability to plug in/charge my phone Storage spots for purse, diaper bag, coffee Teen User Requirements Room for band equipment (guitar, drums, amps) Ability to transport 7 adult band members Ability to get from home – downtown Ability to charge my iPad and play video games Ability to hold can of Mountain Dew Dad User Requirements Room for hunting/camping equipment Ability to transport 2 large dogs Ability to get from home – Montana Backroads Ability to power my camping mattress inflator Ability to hold a super-sized, big-gulp beverage System Key Features 50 Cubic Feet of Storage in Back Seat room for 7 passengers Ability to navigate all road types 4 Wheel Drive Engine Power Speed Controls Steering Controls Braking Controls Power receptors Cup holders/Storage Console (Akin to SDD Verbiage) (Akin to UI Mocks)

3. Designing the User Experience: Know your Users While it may seem obvious, having robust user descriptions is actually an area that is often under-defined. A listing of users is not adequate if we want to build the right interfaces, mostly because we must have extensive understanding of our user demographics to be able to choose the right language, help text, imagery, and UI organization. While we don’t have a strict process of generating and using User Persona’s (an extreme but highly effective way of managing user-centric design), it is important to keep these things in mind about the users of the system if we want to be able to design the right UIs: The primary objective of each UI is to enable the user to do their jobs without having to think twice about how to do it… Age ranges/interest areas Experience with technology (computers, software, email) Attitudes towards technology Those tasks that are most critical for them to perform Those tasks that are most commonly performed (should be front and center in a UI) The job-related areas that currently cause the greatest pain

4. Designing the User Experience: Where to Start As the early SME sessions are taking place (and an iterative define/design pattern is underway), and the key components of the system begin to emerge. After the 3 rd or 4 th user describes a point where they need to initiate a case (possibly of different types), it becomes clear that the system will need to have a feature to “initiate cases”. This is how the SDD emerges…in an iterative requirements gathering/synthesizing exercise. In most cases, the Key Features of a solution (represented in the SDD) can be gleaned in the first few days, or the first 20% of requirements gathering time. The remaining 80% of requirements gathering time is spent decomposing the features across user groups, to learn all of the details and business rules that exist within each key feature. Once you have a solid SDD, you can walk through the system features and put a sticky note at each spot that would require a specific interface for the user…

5. Designing the User Experience: Identify UI Details Once each key UI is identified, fill out each sticky with the details of what needs to be managed by this UI. You don’t need all the details yet, but enough to represent the main purpose of each UI. Next, arrange (and re-arrange) the sticky notes until you find an organization that makes sense in terms of how the users do their jobs… User Login User Name Entry Password Entry Buttons: Login Cancel Retrieve User Name Link Initiate Case Search Client Name Select Client (table?) Select Case Type Select Suspense Date Select Case Worker Case Initiation Date Client Details Creating a “site map” can help determine what type of navigation makes sense…

6. Designing the User Experience: Rough UI Mocks After you have a set of UIs, and know in general what functionality each UI allows, you are ready to mock up the screens. There is a huge benefit in having initial mocks be wire- frames/sketches (i.e. Balsamiq). This way, users don’t get too attached to “look & feel” or element details that may not be feasible for implementation. User Login User Name Entry Password Entry Buttons: Login Cancel Retrieve User Name Link (We are looking into some UI mock up technologies that will prevent this problem… and allow our UI Designers to rapidly generate camera-ready mocks that integrate into our implementation technologies… more to come.)

7. Designing the User Experience: Basic Usability Guidelines When choosing UI elements, there are some basic best-practices guidelines to remember… Group “like” items together (i.e. address fields, case file action buttons, etc) Match UI elements to the action or content type (Balsamiq provides a great library) Radio buttons for times when the user chooses 1 from a short list Dropdown List for times when the user chooses 1 from many Check Boxes for times when the users chooses 1 or many If it looks like a button, it should act like a button Where there are conventions, use them (prevent unnecessary confusion) Help icon is a question mark, no need to get creative here Close button is an x Underlined text is a link Words matter – use the USER’s words, not system-centric words, and less is more A picture can be worth 1000 words – don’t underestimate what icons can do Remember 508 – (i.e. color alone cannot be used to indicate information such as state) Think like a User

8. Designing the User Experience: Mock Deliverable Once the User Interfaces are done, it is time to review/update iteratively, in the context of the UI Mock deliverable format. This continues until the design is “Done Enough” – which is a point of “completeness” that is agreed upon by both the customer and implementation team. Notice that the Mocks are presented in a PowerPoint with each screen represented as a picture and with a bulleted list of key actions for this UI. An SDD indicator is included on each slide with a highlight of the step in the SDD where this UI lives. This format makes it very easy to walk/talk through the proposed application for iterative SME sessions or for final solution overview.

9. Key points to remember… Summary The User Experience needs to be designed/architected User Requirements are “raw”, and need to be synthesized into System Specifications (de-duplicated, simplified, etc) User Interfaces follow/emerge with the SDD, so as you walk through the system capabilities, the required UIs begin to emerge Think like a user when choosing words, icons, and organizing content on each UI Make the UI mock part of the define/design iterations – starting very soon in the process with iterative feedback Designing the User Experience