• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Final wireframes  from screen concept to user interaction v0.4
 

Final wireframes from screen concept to user interaction v0.4

on

  • 1,354 views

 

Statistics

Views

Total Views
1,354
Views on SlideShare
1,354
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Final wireframes  from screen concept to user interaction v0.4 Final wireframes from screen concept to user interaction v0.4 Presentation Transcript

    • Wireframes – from screen concept to user interaction Mia Horrigan IT Strategic Advisor and Architect
    • The Pacifier
      • “ We do this my way . There is no highway option”
    • It all began with a team under pressure
      • Command and Control
      • A template to fill out
      • Attitude of PM - just get it done, don’t question, we’ll worry about fixing it up later
      • this just won’t work
    • Information Architecture journey
    • Analysing users’ problems
      • Talked to end users to find out what they are wanting to do
      • Found out about the current process
      • Looked at needs to improve efficiency and effectiveness
      • Needed to balance need for transparency and accountability with data reporting requirements
      • Identified where functions could be automated
      • Looked at options for system (enhance current, new system, do nothing)
    • Analysis documented as BPMs
      • Focused on what data needed to be captured & when
      • And then developed wireframes
      Requirements Mgmt System
    • Wireframes as screen concepts
      • Designers and programmers need to understand how the screen will work and what it will look like
      • Wireframes give the analysts view of how the system might work from the user perspective
      • …… but sometimes there are problems
    • Wireframes as concepts reflecting understanding of the Requirements
      • It’s not just about building stuff, its about building stuff better
      • Requirements and analysis often done up-front (waterfall approach)
      • Wireframes as screen concepts are often driven by the “as is” process
      • Heavily dependent on data needs and processes
      • May follow an atomic, database driven representation of the web site
      • What I found was this process driven approach didn’t translate into a useable interface, it wasn’t intuitive!
    • Business Requirement Specification
      • “ These concept screens for the [client] website are presented as a guide to the content of the screen (i.e. the attributes and options on a screen) rather than the layout of a screen. The layout (including field sizes, colours, graphics etc.) shall be determined by the technical staff with reference to design standards. The following screens should not be used to indicate the final layout and look of a screen.”
      • BAs are often told not to pre-empt the solution in their requirements however this does not mean that Requirements elicitation and Wireframes should be developed in isolation to the User needs and the context of their situation and behaviour
      User
    • Our problem …process & data driven wireframes and scenarios More reflective of the Physical Data Model vs. User Need 150 wireframes
    • Example Wireframes Tabs used to reflect change in state However when click on tab identical info repeated (not new info) Secondary navigation originally proposed to be hardcoded into each screen Screen reflected an electronic copy of the manual application form – little value add Sequencing was not in line with how the users would work through an application Screens developed as separate screen concepts without view of bigger picture usage scenario
    • What went wrong
      • Focused on replicating the process online
      • Our scenarios were driven by the processes and data requirements and not the user needs
      • User scenarios derived from algorithms (eg pricing info not derived)
      • Wireframe concentrated on data capture (end to end 206 clicks to complete a basic new application process)
    • 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
    • Technical Debt
      • “ Technical debt and design debt refer to the eventual consequences of slapdash software architecture and hasty software development” Ward Cunningham
      • Cost pressure - Functionality scaled back without addressing user experience implications of the decisions
      • Analysis paralysis – over focus on data and process meant little time to think about useability and user interaction needs
      • Time pressure – Only interested in if it was “not broken” …...“besides, we are going to train them”
      • Racking up technical debt to be paid in subsequent releases!!!!!!!!
    • Balancing Priorities of Users to reduce technical debt
      • Project success hinges on Users therefore we needed to:
      • Understand what they want
      • Uncover what they need
      • Look at the context and issues
      • Understand the user behaviour (their online interaction)
      • Show how the process will help users in their work
      • Design the process and system for users
    • Agile Alliance Manifesto
      • While there is value in the items on the right, we value the items on the left more
      • Users vs Process
      Individuals and interactions Processes and tools Working software Comprehensive documentation Customer collaboration Contract negotiation Responding to change Following a plan
    • Agile, Lean & Continuous Improvement
      • Agile -software development methodologies originated as a response to so called “fat” and slow software development processes that increased lead time, work in progress and value/non value added activities ratio
      • Has concepts from Lean Thinking and organises work in a cross-functional, multidisciplinary work cell
      • Focus on continuous improvements, that is the base of Lean
      • Why did we find this a better approach……
    • Adapting to our changing environment
      • We needed to incorporate new info as it came to light and learn from each iteration
      • We proposed an Agile approach as a way to :
      • Maximise value to end user
      • Reduce waste/cost
      • Improve r esponsiveness and service levels for users
      • Minimise risk
    • So we re-organised…
      • Adopted an agile approach
      • Partnered BAs with IA (streams of activities)
      • Consulted with Tech Solution lead during analysis and design to convey features
      • Used “skinny” documentation to quickly convey understanding to stakeholders of the key features of the system and its processes and the flow of information
    • Agile Approach – User Centered Prioritised feature sets Multidisciplinary team and Product owner working together Standards based ISO13407 Consult Tech Team regarding options and desired functionality
    • And we used new tools
      • We utilised Information Architecture tools and techniques to develop:
      • User profiles (Personas)
      • Want maps
      • User Scenarios
      • Prototype (pulling the Wireframes and User scenarios together)
      • Focused on continuous improvement - Iterated our prototype and validated the solution with users
    • Understanding Users - Personas
      • Started off with ‘skinny’ view of users gained thru workshops
      • Built up personas as we went through our iterations, rather than all-at-once
      • Added to personas as info uncovered
    • From skinny to Zen personas
      • As our project knowledge evolved, we added to our understanding of users:
      • Their information preferences
      • Their expectations
      • Their capabilities
      • Their information needs
      • Their social network profiles (Forrester’s Technographics)
      • Documented as ‘ZenAgile’ personas
    • The result – ZenAgile Personas Wants Communication preferences Context Behaviour Motivations
    • User Segmentation – What they want Central office Key Stakeholders Want Map Really effective tool and point at which we started to see buy in from our end users
    • Want Maps to User Needs
    • User scenarios – Story Cards
      • Describe usage at a high-level summarising overall usage functionality that actors will have with the system
      • The usage scenarios highlight the user requirements as they as expressed as a feature set or story card
        • As a [ USER/PERSONA ]
        • I want to [ ACTIVITY ]
        • in order to [ OUTCOME ]
      • These feature sets will then be prioritised by the users during the iterations of development
    • Wireframes to Prototypes
      • Utilising the story cards and usage scenarios we were able to convert the wireframe screen concepts into a prototype reflecting the way users would interact with the system
      Branding Branding Branding This is where the user really got excited and understood what the system would look and feel like
    • Wireframes from screen concepts to user interaction
      • We knew that wireframes combined with scenarios would be a good way to test concepts and see how the system will work for Users
      • Our Wireframes need to reflect the user needs and how they wanted to interact with the system
      • Wireframes should not be developed in isolation to design principals and part of our success was having BAs and IAs working together
    • We adopted IA Design Principals
      • Organise information by type of information
      • Category : Similarity or relatedness. Used when clusters of similarity exist , or when users will naturally look for information by category
      • Time: Chronological sequence
      • Location : Geographic or spatial reference. Used when orientation and information is meaningfully related to the geography of a place
      • Alphabet: Alphabetical sequence
      • Continuum: Magnitude (most to least relevant, largest to smallest, best to worst, etc)
    • IA Design Principals cont…
      • Hierarchy
      • Simplest way to visualise and understand complexity
      • To maximise clarity and effectiveness of hierarchical structures, selectively reveal and conceal
      • Progressive disclosure
      • Only necessary or requested information is displayed at any given time.
      • Prevents information overload and reduces information complexity (Especially useful for novice or infrequent users)
    • IA Design Principals cont…
      • 80/20 rule
      • A high percentage of a system's use comes from a low percentage of its features and content:
        • Focus on the most important features and information
        • Bring the most important information to a high level, and provide multiple ways of accessing it
    • Many ways to get to the same info - Consistency, Redundancy & Entry Points
      • Consistency
      • Comprehensibility is improved when similar parts of the system are expressed in a similar way – ability to learn
      • Redundancy
      • Provide multiple ways to reach same information or features
      • Entry Point
      • Points of prospect should facilitate rapid orientation. Progressive lures to attract and pull users beyond top level (eg news about program and link to full info
      Reporting system
    • What we learnt
      • Engage Users to uncover needs and develop feature sets and user scenarios
      • Work as a team - BA/IA Design team and consult Tech team
      • Use IA tools and techniques to effectively communicate user needs, feature sets and user benefits
      • Agile approach helped us to adapt and build the team based on JIT assessment of what’s needed
      • Concentrate on what users need to quickly and efficiently interact with the system to get their work done
      • Involve users in validation to increase adoption of and buy-in
    • Our Mapping of the User experience 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
    • We found success depends on
      • Understanding Business objectives and processes is important but:
      • Also need to anticipation of future trends and have an ability to sense upcoming developments in order to design and build great applications and websites
      • Work as a team and think about the whole picture and not just our piece of the puzzle
      • Importantly …..
      • Understanding Users, their needs and their behaviour is critical
      • It’s not about You! It’s about Users
    • Understand Users
      • Hinges on communicating with Users:
      • To understand what they want
      • To set expectations about what the project will actually deliver (and what it won’t)
      • To show them how the project will help them in their work
      • To uncover what they need . . .
    • Thank You
      • Mia Horrigan
      • PricewaterhouseCoopers
      • Twitter @miahorri
      • #IA #UCD #agile
      • Blog zenagile.wordpress.com
      • Email mia.horrigan@au.pwc.com