View
1.423
Download
0
Embed Size (px)
DESCRIPTION
Citation preview
Wireframes – from screen concept to user interactionMia HorriganIT 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
ad Maj or / Minor Listing (incl relation to capabilitie s & ucs)
What type ofsubmissionis i t?
Acti vi tyIni ti al
Agree on new / amendedlisting conditions
Register Major / MinorSubmiss ion
PBPA Consideration
(from PBPA Considera tion)
Is there arestriction?
Pricing SecretariatConsideration
High Cost Drugsev aluation
«Sub Process»Finalise Data for
publication
(from Sub Processes)
Is i t a T ier 3subm ission
DUSC High Cost DrugRe-ev aluation
«Sub Process»Pricing section negotiateflow -on listing changes
(from Sub Processe s)
Process Minor Submissions
Submission is ev aluatedby RWG Pre PBAC meeting
Submission is ev aluatedby ESC
Submission is ev aluatedby DUSC
Prepare PBAC Agenda,conduct meeting and
finalise minutes
(from PBAC Consideratio n)
Submission is ev aluatedby RWG
Is Confirmed T ierstatus = T ier 1?
«Sub Process»Pricing QA
(from Sub Processes)
«Broadcast»Add to PBPA Age nda
Is i t a m inorsubm ission?
«Sub Process»High Cost Drugs QA
(from Sub Processes)
Is i t a HighCost Drug?
(from Release 1 Use Cases)
UC29 M anage Committee Agendas
«Broadcast»
Rev ise Prov isional Tier Status
(from Release 1 Use Cases)
UC03 M aintain Submission
«Send»Request PB11a from
client
«Receive»Receiv e PB11a from
clientHas PB11abeenreceived?
«Broadcast»Reference receipt of
PB11a in document list
(from Release 1 Use Cases)
UC19 M aintain Maj or submission document list
HCD section ne gotiateflow -on listing changes
2.10: Abi lity to manage flow-on product changes:
(from Business Requi rements)
2.11: Abili ty to record l isting submission status, (eg draft, ready for export, exported)
(from Business Requiremen ts)
2.12: Abili ty to manage effective dates to control when a change to the PBS i s exported for publ ication
(from Business Requiremen ts)
2.13: Abi lity to record receipt of essential docum entation
(from Business Requi rements)
2.14: Abil ity to record qua lity assurance approval status
(from Busin ess Requi rements)
2.1: Abi li ty to enter and edit submission and li sti ng detail s
(from Business Requi rements)
2.9: Abil ity to record or am end individ ual product prices and perform essential calculatio ns (eg Ex-m an to DPMQ) using correct pri cing mo del
(from Business Requiremen ts)
2.2: Abil i ty to record and amend commi ttee , m embership, meeting and agenda detail s
(from Business Requi rements)
2.3: Abil ity to record PBAC and PBPA recomm endations
(from Business Requi rements)
positive outcomefrom PBAC?
«Broadca st»Reject submission
«Broadcast»Update submission state to Proposed PBPA Secretariat
Acti vi tyFinal
«Broadcast»Update submission state
to Proposed PBAC Secreta riat
«Broadcast»Update s ubmission state to
Finalised
[M inor]
[Yes]
[Yes]
[Yes]
[Yes]
[Yes]
[No]
«reali ze»
[M ajor]
[No]
«reali ze»
«reali ze»
«reali ze»
«real ize»
«reali ze»
«real ize»
«reali ze»
«real ize»
«reali ze»
«reali ze»
«reali ze»
«real ize»
«reali ze»
«reali ze»
«reali ze»
[No]
«reali ze»
«reali ze»
[No]
«reali ze»
«reali ze»
«reali ze»
[No]
[No]
[No]
[Yes]
«reali ze»
[Ye s]
«reali ze»
«reali ze»
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 RequirementsIt’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
stateHowever 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 wrongFocused 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 environmentWe 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 responsiveness 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
Identify users’ needs
Develop
FeaturesFeatures
Understand context of use
Produce design
solution
Specify user andbusiness
requirements
Evaluate/validate
with users
Features
Prioritised
feature sets
Multidisciplinary team and
Product owner working together
Standards
basedISO1340
7
Consult Tech Team
regarding options and
desired functionality
And we used new toolsWe 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 personasAs 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 PrototypesUtilising 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
BrandingThis 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 featuresEntry 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
processWorkshop processes and user
requirements
As a User (Persona)
I want to [Activity] User Need
In order to [Outcome] Bus Benefit
EMG View succinct and meaningful High Level Overviews of Organisational and Business
UN1, UN10
Understand how FaHCSIA is tracking on key issues
BB-1, BB-2
Developed usage
scenarios – feature set (story cards)
Iterated improvement
s to user interface in prototypes
Feature No. Business Benefit (BB) Addresses User Need
Snapshot view of top priorities/issues for FaHCSIA
BB-1
Clarity - Will give clarity of how the organisation is tracking against key outcomes and initiatives that are the current focus. Definable dashboards can show leading/lagging, progress against goals, deviations, exceptions, trending, part-to-whole, geographic/spatial performance, rankings, time series, correlations, distributions etc. (The content of what to include in the top level view can be changed and updated).
UN-1, UN-10, UN-16, UN-20
Uniform presentation format
BB-2
Consistency - Consistent look and feel to reports will aid understanding of how the report works, where data is sourced and when and what it is trying to portray. May aid analysis and interpretation of reports and enable comparison across groups and highlight linkages and correlations across areas and different reports.
UN-9, UN-15
Quality of data input
BB-3
Data Quality and Assurance – business area responsible for the data input and ensuring the information is correct. Accountability and ownership of the data by the appropriate data custodian will increase confidence that the data is correct. (Data Dictionary will help to have a common understanding of data definitions across the organisation).
UN-3, UN-5, UN-17
Validated prototype with usersTranslate
d 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 UsersHinges 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 YouMia HorriganPricewaterhouseCoopers• Twitter @miahorri#IA #UCD #agile• Blog zenagile.wordpress.com• Email [email protected]