User needs vs buisness needs v5a


Published on

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • We are a multicultural society Cultural impacts may include: family, gender, peer group, religion, political beliefs etc Be aware of your attitudes and how they may impact on service delivery Understand any cultural issues being experienced by your users If you are congruent and have established rapport, you are in a position to be culturally sensitive and hence to interact effectively with your client.  
  • User needs vs buisness needs v5a

    1. 1. User Requirements vs Business Needs Mia Horrigan Manager - IT Advisory Services Twitter @miahorri #agile #UCD BA World Aug 2010
    2. 2. My cultural experiences Slide
    3. 3. …… . what if the culture of your users is different to your own? Slide
    4. 4. Unique Culture of the Users <ul><li>We are a multicultural society </li></ul><ul><li>Cultural impacts may include: family, gender, peer group, religion, political beliefs etc </li></ul><ul><li>I needed to be aware of my attitudes and how they may impact on service delivery </li></ul><ul><li>Understand any cultural issues being experienced by the users </li></ul><ul><li>I found that if you are congruent and have established rapport, you are in a position to be culturally sensitive and hence to interact effectively with your users. </li></ul><ul><li>  </li></ul>Slide
    5. 5. Situation <ul><li>System was required to develop a consolidated reporting tool that would bring together 6 different programs </li></ul><ul><li>An existing system was in place so business proposed to enhance this system to capture the needs of the other 5 programs </li></ul><ul><li>The business needed reports and quickly (hence opting for the existing system) </li></ul><ul><li>The user priority was to deliver services so there was a disconnect. </li></ul><ul><li>The users also had unique cultural issues </li></ul>Slide
    6. 6. The answer to life the universe & everything Slide <ul><li>The business had a product solution in mind </li></ul><ul><li>This was before the business had engaged with users and stakeholders </li></ul>
    7. 7. The business already had the answer… The challenge for me was to find out the question <ul><li>Business need – web portal reporting tool, already had a solution, wanted me to validate this choice </li></ul><ul><li>vs </li></ul><ul><li>User requirement – funding (if they provide reports they get ongoing funding), management tool for service delivery </li></ul><ul><li>Analyse what the users need and want and then determine if the proposed solution aligns to these needs </li></ul>Slide
    8. 8. Was the proposed solution the right one? <ul><li>Up front analysis as business needed to know what option to go with and asked for our recommendation </li></ul><ul><li>Enhance current reporting tool </li></ul><ul><li>GOTS/COTS </li></ul><ul><li>Proprietary tools integration </li></ul><ul><li>Do nothing – continue with current disparate systems </li></ul>Slide
    9. 9. Business Needs vs User Requirements <ul><li>Is it enough to just understand what the business needs out of a project? </li></ul><ul><li>What about system requirements? </li></ul><ul><li>Where does this user fit into this picture of the business and IT landscape? </li></ul>Slide
    10. 10. User engagement is difficult Slide
    11. 11. this project would be great if I didn’t have to deal with users <ul><li>Users aren’t a nuance! </li></ul><ul><li>They are vitally important to your success </li></ul><ul><li>You must take time to understand what they need </li></ul><ul><li>Modern Users are sophisticated (Web 2.0, Gov 2.0) </li></ul><ul><li>Have expectation of how applications should work </li></ul><ul><li>Don’t just dismiss user’s needs because it is difficult </li></ul>Slide
    12. 12. Unique user issues <ul><ul><li>Rural and remote access to community </li></ul></ul><ul><ul><li>Varying capability to deliver program reporting across the services </li></ul></ul><ul><ul><li>Difficult to attract skilled personnel to remote areas </li></ul></ul><ul><ul><li>Reporting burden (focus was on service delivery) </li></ul></ul><ul><ul><li>Cultural and language barriers (English was a second language) </li></ul></ul>Slide
    13. 13. Rural and remote challenges <ul><li>Communication </li></ul><ul><ul><ul><li>Broadband </li></ul></ul></ul><ul><ul><ul><li>Satellite </li></ul></ul></ul><ul><ul><ul><li>Mobile network/3G </li></ul></ul></ul>Slide Photo: Glenn Campbell
    14. 14. The mobile analyst Slide <ul><li>Geographical </li></ul><ul><ul><ul><li>Wet/dry season </li></ul></ul></ul><ul><ul><ul><li>Distance </li></ul></ul></ul><ul><ul><ul><li>Modes of transport </li></ul></ul></ul>
    15. 15. Our Users were culturally diverse Slide
    16. 16. Language and terminology Slide
    17. 17. Cultural sensitivities of our Users <ul><li>Be respectful of men’s and women’s business when it is occurring in a community </li></ul><ul><li>Ensure that respect and distance is maintained when there is a death in a community </li></ul><ul><li>That should a person die, their name is not to be spoken in front of any other indigenous people </li></ul><ul><li>Minimal footprint approach to local consultation needs to occur </li></ul>Slide
    18. 18. What this meant for our project <ul><li>Needed to understand </li></ul><ul><li>Mobility of some Indigenous peoples – follow them to new roles to assess the full impact of workforce development strategies </li></ul><ul><li>Maintaining an informal stance to ‘on the ground’ data collection where discussions will be held without technical aids and without the usual formal tools and techniques of interviewing </li></ul><ul><li>Having an understanding of the impact of the wet season and dry conditions on accessibility / travel and individual participation </li></ul>Slide
    19. 19. Analysing users’ problems <ul><li>Talked to the community to find out what they wanted </li></ul><ul><li>We listened to their stories </li></ul><ul><li>Found out about the current process </li></ul><ul><li>Looked at reporting needs to provide feedback on funding projects </li></ul><ul><li>Balance need for transparency and accountability with users practical requirements </li></ul><ul><li>Identified where functions could be automated </li></ul><ul><li>Looked at options for system (enhance current, new system, do nothing) </li></ul>Slide
    20. 20. And we used new tools <ul><li>We utilised a User Centered design approach </li></ul><ul><li>Up front analysis of requirements however incorporated Agile artefacts </li></ul><ul><li>Used Information Architecture tools and techniques </li></ul><ul><li>Focused on continuous improvement </li></ul><ul><li>Iterated our prototype </li></ul><ul><li>Validated the solution with users </li></ul>Slide
    21. 21. User Centered Approach - Agile Prioritised feature sets Multidisciplinary team and Product owner working together Standards based ISO13407 Consult Tech Solution Team regarding options and desired functionality Slide
    22. 22. “ Watergile” Slide
    23. 23. Agility and responsiveness to Users didn’t mean chaos and scope creep Slide
    24. 24. Agile artefacts to display requirements <ul><li>Our audience was very visual, so were our artefacts </li></ul><ul><li>Personas - Archetypal users wanted and how they differ in what they require </li></ul><ul><li>Want maps - Key difference and commonalities of wants across the varied stakeholders </li></ul><ul><li>Process maps - Help users through the process, streamline the process and reduce duplication of information </li></ul><ul><li>Prototypes – Look and feel of the system and get see if it is useable and meets needs </li></ul>Slide
    25. 25. Understanding Users - Personas <ul><li>Started off with ‘skinny’ view of users gained thru workshops </li></ul><ul><li>Conducted workshops and consultations with users in their community </li></ul><ul><li>Built up personas as we went through our iterations, rather than all-at-once </li></ul><ul><li>Added to personas as info uncovered </li></ul>Slide
    26. 26. The result – ZenAgile Personas Wants Communication preferences Context Behaviour Motivations Slide
    27. 27. Personas used to communicate purpose <ul><li>Demonstrate understanding of key users </li></ul><ul><li>Told their story through scenarios and explained why they wanted what they wanted from the system </li></ul>Slide I don’t have time to do reporting I want a tool to help me manage my program
    28. 28. User Segmentation – What they want Central office Really effective tool and point at which we started to see buy in from business as they understood user needs Key stakeholder want map State /Territory office Department State Department Slide
    29. 29. Want Maps to User Needs Slide
    30. 30. Translator between Users and Business Slide Business Me User
    31. 31. The different wants Slide I want reports to assess if program and policy aims are being achieved Business Me User I want to deliver services on the ground to help who need them We should build a web portal
    32. 32. We documented analysis as BPMs <ul><li>Focused on what data needed to be captured & when </li></ul><ul><li>And then developed wireframes </li></ul>Requirements Mgmt System Slide
    33. 33. Wireframes as concepts reflecting understanding of the Requirements <ul><li>It’s not just about building stuff, its about building stuff better </li></ul><ul><li>Requirements and analysis was done up-front </li></ul><ul><li>However…. Our wireframes were driven by the “as is” process. </li></ul><ul><li>This process driven approach didn’t translate into a useable interface - it wasn’t intuitive! </li></ul><ul><li>Need to think about the future state (technology, process and people needs) </li></ul>Slide
    34. 34. Some initial problems…. Using the report form didn’t really relate well to the user want maps to simplify and streamline Our scenarios built on the form data capture process resulted in screens that did not flow well, and lots of clicks from end to end Secondary navigation originally proposed to be hardcoded into each screen Screen reflected an electronic copy of the previous report form – little value add Sequencing was not in line with how the users would work through providing the information Screens developed as separate screen concepts without view of bigger picture usage scenario Slide
    35. 35. What we should have considered Not just about the process … .or the technology Its about Users and how they work ..and the context of their work Slide
    36. 36. User scenarios – Story Cards <ul><li>Describe usage at a high-level summarising overall usage functionality that actors will have with the system </li></ul><ul><li>The usage scenarios highlight the user requirements as they as expressed as a feature set or story card </li></ul><ul><ul><ul><li>As a [ USER/PERSONA ] </li></ul></ul></ul><ul><ul><ul><li>I want to [ ACTIVITY ] </li></ul></ul></ul><ul><ul><ul><li>in order to [ OUTCOME ] </li></ul></ul></ul><ul><li>These feature sets will then be prioritised by the users during the iterations of development </li></ul>Slide
    37. 37. Feature Sets Slide As a [User/Persona] I want to [Activity] In order to [Outcome] CEO View succinct and meaningful High Level Overviews of Organisational and Business Understand how my service is tracking on key issues CEO Make decisions based on the report information (both quantitative and qualitative information) Proactively manage my service as a business and respond to issues in my community Program Manager Measure and Track Financial Performance of the Departmental Budget and Administered Expenses Understand the variance in Performance from Budget vs. Forecast vs. Actual and monitor how my agency is tracking against the PBS Branch Manager Timely updates of information (Real time information as information is of no use if it is old or out of date) Be able to understand trends and track progress and achievements against organisational and business KPIs. Timing and frequency of information should be based on need for that information
    38. 38. User Needs Slide User Need Responsibility Description of User Need UN-1 System + Business To produce report on key outcomes, outputs and critical business activity. Information must be relevant and able to be acted upon by the Executive. UN-2 Business Decreased duplication across reports. It was stated that there are a lot of reports that overlap. Users want rationalisation of reports as it was expressed that the group does not want the executive dashboard to be another report on top of current reporting workload. UN-3 Business + System Confidence in the Quality of the data. Data cleansing exercise may be required and business needs to be accountable and take ownership of the data in their area. UN-4 Business Corporate (Financial and HR) and Business (Program and Payments) information. Situation Report is focused on Programs and based on Ministers’ need - not a comprehensive report for the business. May need more comprehensive Program and Payments level data for Branch and Section Managers. Financial data tracks administered funds but also want to track committed funds. UN-5 System + Business Decreased burden of reporting (takes a long time to pull all the information together and there are a number of reports to be complied on a weekly, monthly, quarterly and annual basis. It was stated that at times they struggle with the amount of reporting required. Need to look at how frequently the information needs to be reported on (as sometimes does not change from week to week or month or month).
    39. 39. Tying Features to the Business Benefit Slide
    40. 40. Information Architecture journey Slide
    41. 41. From wireframes to user interaction <ul><li>We knew that wireframes combined with scenarios would be a good way to test concepts and see how the system will work for Users </li></ul><ul><li>Our Wireframes needed to reflect the user needs and how they wanted to interact with the system </li></ul><ul><li>Part of our success was having BAs and IAs working together </li></ul><ul><li>Eventually our Wireframes were not developed in isolation to design principals </li></ul>Slide
    42. 42. We adopted IA Design Principals Slide <ul><li>Organise information by type of information </li></ul><ul><li>Category - Similarity or relatedness. Used when users will naturally look for information by category </li></ul><ul><li>Time - Chronological sequence </li></ul><ul><li>Location - Geographic or spatial reference. Used when info is meaningfully related to geography of a place </li></ul><ul><li>Alphabet - Alphabetical sequence </li></ul><ul><li>Continuum - Most to least relevant, largest to smallest, best to worst, etc) </li></ul>
    43. 43. IA Design Principals cont… <ul><li>Hierarchy - Simplest way to visualise and understand complexity. Maximise clarity by selectively reveal/conceal </li></ul><ul><li>Progressive disclosure - Only necessary or requested information is displayed at any given time. Prevents information overload and reduces information complexity </li></ul><ul><li>80/20 rule - A high percentage of a system's use comes from a low percentage of its features and content. Focus on most important features & information and bring to a high level </li></ul>Slide
    44. 44. People think about info in different ways <ul><li>Consistency - Comprehensibility is improved when similar parts of the system are expressed in a similar way – ability to learn </li></ul><ul><li>Redundancy - Provide multiple ways to reach same information or features </li></ul><ul><li>Entry Point - Points of prospect should facilitate rapid orientation. Progressive lures to attract and pull users beyond top level (e.g. news about program and link to full info </li></ul>Slide
    45. 45. Many ways to get to the same info Slide Reporting system
    46. 46. Screen Concepts to Prototypes <ul><li>Utilising the story cards and usage scenarios we were able to convert the screen concepts into a prototype reflecting the way users would interact with the system </li></ul>Branding Branding Branding This is where the business owner and the users really got excited and understood what the system would look and feel like Slide
    47. 47. Prototype helped Business acceptance of requirements <ul><li>Easier for business to relate to and understand the user needs </li></ul><ul><li>Able to see the value in responding to the needs - would help gain acceptance and create quick wins </li></ul><ul><li>Presenting Use Case after Use Case, would have missed the mark with this group - too detailed and technical and does not give the same feel for what the users wanted </li></ul><ul><li>Story telling and visual cues very appropriate for this user audience </li></ul>Slide
    48. 48. Compared options Slide <ul><li>The User requirements were identified and prioritised </li></ul><ul><li>Business Needs and constraints for system noted </li></ul><ul><li>System options compared to user and business needs </li></ul>
    49. 49. Win/WIN or WIIFM? Slide
    50. 50. Reporting vs management tool <ul><li>x% and variance of health checks </li></ul><ul><li>Comparison to state and national </li></ul><ul><li>Trend over past 12 months </li></ul><ul><li>PIRS data capture & upload </li></ul>Slide Example only
    51. 51. Visual Display Slide
    52. 52. Appropriate context Slide
    53. 53. Win Win <ul><li>For the User: </li></ul><ul><li>Reports that I understand. I see value in providing data </li></ul><ul><li>Useful reports that help me decide what to do </li></ul><ul><li>Compare me to communities like me </li></ul><ul><li>I am still the data custodian and can provide context </li></ul><ul><li>For Business: </li></ul><ul><li>I have the information to give to executive </li></ul><ul><li>Report provided in one system in the same format </li></ul><ul><li>Quality of data improved </li></ul><ul><li>Extra features for users but meet my needs </li></ul>Slide
    54. 54. What we learnt <ul><li>Engage Users to uncover needs - develop feature sets and user scenarios </li></ul><ul><li>Use IA tools and techniques to effectively communicate user needs and benefits </li></ul><ul><li>Concentrate on what users need to efficiently interact with the system to get their work done </li></ul><ul><li>Involve users in validation to increase adoption and buy-in </li></ul><ul><li>Understanding Users, their needs and behaviour is critical </li></ul><ul><li>It’s not just about the business, It’s about being responsive to needs of all the Users </li></ul>Slide
    55. 55. Incorporating business & users needs Understood user needs and wants Mapped business process Workshop processes and user requirements Developed usage scenarios – feature set (story cards) Iterated improvements to user interface in prototypes Validated prototype with users Translated user needs into features and benefits Slide
    56. 56. Why was this approach successful? <ul><li>Business was taken through the requirements development process </li></ul><ul><li>Visual clues showed them what the user experience would be like </li></ul><ul><li>Personas helped them relate to the users and took on a life of their own </li></ul><ul><li>Could see how the design and system would work </li></ul><ul><li>Brought along on the journey </li></ul><ul><li>Story told through the eyes of the users </li></ul>Slide
    57. 57. Thank You <ul><li>Mia Horrigan </li></ul><ul><li>Twitter @miahorri </li></ul><ul><li>#UCD #user requirements </li></ul><ul><li>Blog </li></ul><ul><li>Email </li></ul>Slide © 2010 PricewaterhouseCoopers. All rights reserved. “PricewaterhouseCoopers” refers to the network of member firms of PricewaterhouseCoopers International Limited, each of which is a separate and independent legal entity. *connectedthinking is a trademark of PricewaterhouseCoopers LLP (US).