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 mia.horrigan@au.pwc.com