‘EASY BOOK & PAY’
DIGITAL CANBERRA
CHALLENGE
BOOKING AND PAYING FOR AN
ACT GOVERNMENT SERVICE
PROOF OF CONCEPT AND CASE STUDY
CONTENTS
Taking a service design approach to digital innovation – what you get ................................... 3 WHAT WE CAME UP WITH - THE DIGITAL INNOVATION ............................................... 4 Proof of concept overview ................................................................................................ 5 The focus .................................................................................................................... 5 The solution ................................................................................................................ 5 The guiding principles for the product, for the service ....................................................... 5 Key features and benefits ............................................................................................. 6 The solution in storyboards ........................................................................................... 8 A Simple technology back-end to a well designed service .................................................13 Proof of Concept URLs .................................................................................................13 WHAT WE CAME UP WITH - THE SERVICE SYSTEM INNOVATION ............................... 15 Who’s involved – service user typologies ........................................................................17 Service system innovation – a ‘Digital First’ Integrated Service System ..............................19 HOW WE GOT THERE - THE DIGITAL CANBERRA CHALLENGE CASE STUDY ................. 20 Our approach ................................................................................................................21 Our Team ..................................................................................................................22 Our ACT Government Collaborators ...............................................................................22 Our NICTA Collaborators ..............................................................................................23 What we did ...............................................................................................................23 How we did it - Our service design approach in focus .......................................................24 What we did in New Zealand – In focus ..........................................................................27 What it was like – Our team reflection on the Challenge process........................................30 What was it like – Reflections on the Challenge itself .......................................................32 APPENDIX 1 – WORKFLOWS ............................................................................................33 Pathway for booking and payment ................................................................................33 Pathway for booking completed and paid online ..............................................................33 Pathway for incomplete booking with payment deferred ...................................................34 Pathway for making deferred payment ...........................................................................34 Pathway for changing date or time of a completed booking ...............................................35
APPENDIX 2 - WIREFRAMES ............................................................................................36 DCC Proof of Concept and Case Study – 17 March 2014
Page 2 of 45
TAKING A SERVICE DESIGN APPROACH TO
DIGITAL INNOVATION – WHAT YOU GET
DMA and our team of professionals were chosen for the Digital Canberra Challenge because we
submitted that a service design approach (understanding and designing for all of the elements
in play in a booking and payment system) would provide outstanding-yet-practical innovation
for our clients, Road User Services (RUS)and more broadly the ACT Government, than a purely
technology based product innovation.
So what do you get with a service design approach?
YOU GET A DIGITAL SOLUTION.
Weeks of research, prototyping and iteration from a multi-disciplinary design team has resulted
in Easy Book & Pay, a simple and elegant booking and payment solution that:
•
•
•
•
Reflects user and government needs.
Is designed in line with evidence-based Service Principles specifically developed for this
project.
Is non-device specific providing multi-platform options.
Is designed to be sustainable in terms of integration with existing Government systems.
Easy Book & Pay is ready to be used now as a Road User Services proof of concept that can be
easily translated to match other RUS booking service offerings.
BUT WAIT, YOU ALSO GET A SERVICE INNOVATION DESCRIPTION.
In addition to a product, the service design approach means we have also delivered a range of
service system insights that will allow RUS to feed their knowledge into a broader oneGovernment approach to digital service provision.
We don’t just HOPE people might use this service, we:
•
•
•
Define the users of the service and how they WILL use it.
Describe the current experience and the barriers and opportunities PRESENTED.
Deliver a description of the features and benefits of a total digital service for BOTH ACT
users and ACT Government service owners.
‘MyACT’ is a digital platform that takes information, interaction and transaction (both
authenticated and unauthenticated) with the ACT Government as a whole and places it at the
centre of the overall service delivery experience.
Not just a licence test, not just a booking and payment, not just Directorate-based service
delivery: but a consistent and professional one-Government interface and experience for
residents, visitors and other Government service users.
AND THERE’S MORE, YOU ALSO GET A CASE STUDY OF INSIGHTS INTO HOW WE GOT
THERE AND WHAT IS POSSIBLE IN ALL ACT GOVERNMENT DIGITAL DEVELOPMENT
The case study not only provides a reflection on the Challenge and what being part of it was like,
it:
•
•
Provides highlights of all of the key stages we undertook including research, prototyping,
iteration and build.
Highlights the international approach we took by collaborating with our New Zealandbased design colleagues, Empathy Design, to ensure we brought in global best-practice.
The Case Study shows the sponsors of the Challenge that implementation of a service design
approach for all levels of government service offerings isn’t just nice to have, it’s necessary.
We hope you enjoy the results and, regardless of the outcome of the Challenge, we
thank you for allowing us to showcase service design in an ACT Government setting.
DCC Proof of Concept and Case Study – 17 March 2014
Page 3 of 45
WHAT WE CAME UP WITH
THE DIGITAL INNOVATION
A digital product where the innovation is both in simplicity of process for users and
the availability of multi-device platforms integrated with existing Government
processes and systems.
DCC Proof of Concept and Case Study – 17 March 2014
Page 4 of 45
PROOF OF CONCEPT OVERVIEW
The focus
The Digital Canberra Challenge set Team DMA the task of creating a proof of concept that met
the challenge of digitizing ‘easier scheduling’.
The example given, and subsequent focus of meeting the challenge from early collaboration with
Road User Services ACT (a Branch of the Justice and Community Safety Directorate (JACS)),
was booking an ACT Government Service – particularly, a licence test.
The proof of concept developed by Team DMA meets this challenge but also broadens the
specific focus to incorporate delivery of:
•
A system and process that allows members of community to book-in and pay for a road
user service (driving test, registration inspection, parking permits, parking reviews, etc)
whilst conceptually enabling the ACT Government to extrapolate the findings and
concept for their whole-of-government requirements.
This focus was firmed through the interactions with representatives of JACS who, as collaborators
and clients within the parameters of the Challenge, have sought to receive the proof of concept in
the spirit of a one-government system, rather than a stand-alone licence booking system.
The solution
With all of this in mind, Team DMA, after undertaking a rigorous service design process –
involving both the Directorate and potential users of the system, presents Easy Book & Pay to
the Challenge judging panel.
Easy Book & Pay takes the insights gathered through the research and prototyping phases of the
competition – along with the operating reality of the government and Directorate systems and
regulatory requirements – to deliver a booking and payment system that:
•
•
Meets the needs of users to book and pay for a government service easily, whilst
understanding their rights and responsibilities.
Supports the goals of the ACT Government to offer innovative but sustainable digital
solutions for simple transactions at a whole-of-government level.
The guiding principles for the product, for the service
These principles, which have been developed from the research, have ensured the design,
development, and any subsequent changes to, an improved booking and payment service will
deliver on user and business needs. They address both the product and service need.
The digital product /
service is designed
to enable users to
successfully achieve
their outcome.
There is reduced
effort to complete
a task online.
The use of the
digital channel is
rewarded.
All common digital
functions are
consistent across
Government.
This means:
This means:
This means:
This means:
• A range of help and
support is accessible
as part for the overall
service.
• Users understand and
can meet their
obligations and the
consequences of not
meeting these.
• The task is achievable
relative to the
outcome.
• The effort required
is outlined upfront.
• Eligibility criteria is
built into the
process.
• Default to familiar
and ‘best practice’
functionality.
• There are incentives
to use it – money,
time.
• Exclusive services
provided in the
digital offering.
• Ability for users to
maintain ‘a record’
of transactions in
partnership with
government.
• Users move through
common steps for
‘like services’.
• The service
experience is the
same regardless of
the Directorate
responsible.
• Value for money (for
the users and
government) drives
development of the
digital offer.
DCC Proof of Concept and Case Study – 17 March 2014
Page 5 of 45
Key features and benefits
This table summarises the service features of the Proof of Concept. These features have been
determined, tested and defined by the potential internal and external users of the system during
the research process.
Product or Service Feature
User Benefits
Business Benefits
Task-oriented user interface
Task-oriented “inductive” user
interface design, focused on
supporting users through defined
workflows as easily as possible.
Information is provided in context,
as and when required to inform
user choices and actions.
• Easy to use without
preparation or previous
knowledge.
• Self-explanatory processes
are smooth, quick and
definite.
• Minimal user support
requirement
• Transactions inherently
comply with business rules
No additional registration
For test bookings, user identity
and eligibility are checked through
existing Learner Licence and
Knowledge Test certificate data.
No additional registration or
passwords are required.
• No additional identity checks
to complete.
• No additional usernames or
passwords to remember.
• Consistent with existing
identity and document
checking processes
• Applies existing user data
• Low risk of data errors
Sharable reminders
Once a booking is made, users
can set multiple email or SMS
reminders to be sent to
themselves and others (carers,
etc). Users can also send or save
confirmations & receipts.
• Helps ensure both applicant
and any other party (eg.
person providing car or
accompanying a learner to
the test) get reminders in
time.
• Reminders can include details
of preparations and
documentation to bring.
• Enables user to keep or copy
confirmation and receipts,
even from mobile phone.
• Helps minimise snags in
testing schedule by
helping applicants arrive
on time, prepared, and
with required
documentation.
• May reduce last-minute
attempts to reschedule
bookings.
Leeway for user decisionmaking
A deferred payment option allows
young learners to ‘put a hold’ on a
booking for a limited period (such
as until the end of the next
business day) and then complete
payment to secure the timeslot.
• Young learners without credit
cards can arrange with
parent/carer to pay.
• Users can check with others
(eg. to ensure car is
available) before committing
to time.
• Users can pay by phone, over
counter etc instead of online
if they prefer.
• Supports efficient use of
existing channels for
payment.
• May reduce inefficiencies
from aborted transactions
and changes/
cancellations.
• Improved user
satisfaction.
Device-independent website
Device-independent, responsive
website design (not an app) for
use on mobile, tablet, PC, kiosk
and other devices. The display
adapts to the available screen size
and other device capabilities.
• Widespread availability on
users’ devices of choice.
• Available at all hours.
• Easy and consistent to learn
to use.
• No installation required.
• Suitable for shopfront
kiosks as well as users’
own devices.
• Minimised development,
deployment and ongoing
maintenance requirement.
• Minimal technical support
requirement.
Comprehensive service
The service deals with anyone
seeking to obtain an ACT Drivers
Licence, including new residents
from interstate and overseas,
providing them with appropriate
options and information.
• Useful for everyone.
• Easy for new residents to
work out what they have to
do and what documentation
they need.
• Accessible outside the ACT.
• Caters to the full range of
licence applicants.
• May reduce inefficiencies
from transactions stalled
by insufficient
documentation.
DCC Proof of Concept and Case Study – 17 March 2014
Page 6 of 45
Product or Service Feature
User Benefits
Business Benefits
Personalised service
The system tracks user status
through the booking process,
even across multiple visits. It
provides prompts and contextrelevant options; for example, to
change or cancel bookings once
made.
• Improves quality of service
and clarity of transaction
outcomes.
• Makes transactions easier by
only offering options and
information relevant to the
user at the time.
• Users can get confirmation of
booking details without
having to print anything.
• Streamlined workflows
support task completion
and minimise inefficiencies
and errors.
• Transactions inherently
comply with business
rules.
• Improved user
satisfaction.
Multi-channel service
A multi-channel service using a
new website alongside existing
call centre and shopfront services;
with potential to extend to other
service channels such as smart
parking meters and the MyWay
ticketing system.
• Better access to service.
• People can choose the service
delivery channels that suit
them best.
• More convenient and flexible
booking and payment
options.
• Improved service quality
overall.
• Some transactions shifted
to lower-cost channel.
• Supports efficient use of
existing channels.
• May reduce inefficiencies
from aborted transactions
and changes/
cancellations.
• Improved user
satisfaction.
• Can also support a wide
range of other ACT
Government services.
Integrates with existing
systems
The system interacts with existing
databases and processes to:
check user identity and eligibility
for tests; view, create and update
test bookings; check payment
status.
• Seamless service.
• Accurate data without
duplicate entry.
• Implementation can be
phased in, with
progressively tighter
integration as appropriate
to demand and resources.
• Minimum disruption to
existing processes and
systems.
DCC Proof of Concept and Case Study – 17 March 2014
Page 7 of 45
The solution in storyboards
A COMMON SCENARIO – STEPHANIE
Stephanie is a young learner driver who has decided to take a test rather than use the logbook
method.
Stephanie goes to the MyACT website and steps through to where she can book her driving test.
Stephanie enters her name and licence details, then picks Dickson as the place for the test.
DCC Proof of Concept and Case Study – 17 March 2014
Page 8 of 45
When she picks her preferred date from the calendar, it opens up to show what times are free
that day (and on the other days that week). She picks the one she wants.
Now she has to pay the booking fee. Stephanie looks at the online payment options, but she
doesn’t have a credit card or a PayPal account.
DCC Proof of Concept and Case Study – 17 March 2014
Page 9 of 45
Instead, Stephanie goes to the ‘Pay within a day’ option. If she can get her parents to pay, she
can book the time she wants. There are several ways to do it, too. She calls her Dad.
Stephanie’s Dad is at
work. He uses his
smartphone to go to
the MyACT website.
Then, he chooses the
‘Pay online now’ option.
He enters his credit card
details.
First, he enters Steph’s
name and details.
DCC Proof of Concept and Case Study – 17 March 2014
Page 10 of 45
When he sees the
confirmation message,
he lets Steph know
she’s booked in.
When Stephanie looks at the MyACT website later, she sees her booking and some options. She
sets two reminders, for herself and her Dad so he leaves work in time for her to have the car.
A week before the test, Stephanie’s Dad finds out he has to be in Nowra that day. Steph can’t
have the car. She has to change the booking… but it’s not hard to do.
DCC Proof of Concept and Case Study – 17 March 2014
Page 11 of 45
Before the test, Stephanie
gets the reminder email she
set up earlier. (Her Dad
gets his reminder, too).
Stephanie remembers to check the detailed instructions provided
with her booking confirmation.
DCC Proof of Concept and Case Study – 17 March 2014
Page 12 of 45
A simple technology back-end to a well designed service
With the evidence presented during the research and analysis phase of the Challenge presenting
the team with key design principles around platform and structure, and also taking into account
that the delivery is of a proof of concept and not a pilot or production version, the technical
implementation was relatively simple.
This is not to say that the implementation recommended would be different in a production
version as the design principles for the tech build reflect the service principles:
•
•
Don't make this simple transaction an 'app' or something in a unique presentation, make
it part of a multi-device offering (from service recipients).
Don't design a front end that requires large-scale back-end reconfiguring and large IT
investment (from service deliverers).
With these principles in mind the technical details for the proof of concept are as follows.
Proof of Concept URLs
PRODUCT: myact.me/bookings
SERVICE SYSTEM: myact.me
TECHNICAL IMPLEMENTATION DETAILS
The proof of concept GUI is written to operate as static HTML files using Angular JS to provide
state logic and to call back-end web services.
Almost all validation and data storage would be contained with in a backend booking service
which would store booking availability, bookings, reminders etc.
An automated system process on the backend would handle sending of reminders, most likely
via third party vendor for SMS, as well as cleaning up expired booking reservations that haven't
been paid for and generating booking sheets for the registered testers. There would be a
backend administration view running on the system to allow Canberra Connect operators to
add/edit booking time slots as well as the ability to manually add and edit bookings (for people
who call instead).
The only initial integration requirement with existing rego.act data would be to validate a driver
record to ensure they were eligible to book a test.
The other external web service connection would be to the payment gateway and PayPal. This
can be done through an embedded iframe or through use of their exposes web API.
WEB SERVICES EXPOSED FROM NEW BOOKING SYSTEM
Below is a breakdown of the web services broken into where they would 'live'.
checkDriver (firstName, lastName, dob, learnerNumber)
firstName and dob can be omitted but result only validates to see if there is an existing booking
for user to pay
learnerNumber could also be a knowledge test certificate number
Checks if there is an existing record for driver; if there is returns this as a JSON object; if not,
passes through record to rego.act web services validateDriver() to check validity
Returns JSON for existing record or boolean for validity of learnerNumber to apply
getLocations ()
Returns JSON of testing locations
DCC Proof of Concept and Case Study – 17 March 2014
Page 13 of 45
getCalendarMonth (location, date)
Returns JSON of available time slots for given location and month
createBooking (firstName, lastName, dob, learnerNumber, location, date)
Creates a booking reservation for user; reserves date
Returns JSON which includes booking number.
cancelBooking (bookingNumber)
Cancels an existing booking
saveReminders (bookingNumber, reminders)
Saves reminders JSON against an existing booking
changeBookingDate (bookingNumber, newDate)
Updates existing record with new booking date; adds fee to outstanding balance
(private) updateBooking (bookingNumber, paymentDetails)
Note: called only by third-party booking service after payment taken.
Updates booking record with payment status and adjusts outstanding balance
Note: additional web services maybe required in development of the administrator view.
WEB SERVICES REQUIRED FROM EXISTING REGO.ACT
validateDriver (firstName, lastName, dob, learnerNumber)
learnerNumber could also be a knowledge test certificate number
PAYMENT GATEWAY SERVICE FOR CREDIT CARD AND PAYPAL
Abstract payment facility which passes through amount and booking number, on success calls
private web service to add payment status to existing booking record.
SERVICE OWNER ADMINISTRATION ROLE
Underpinning the utilisation of the Book and Pay by a range of Government agencies and service
deliverers is the concept of developing ACT Government Service Owners.
The Service Owner (Directorate agnostic) are provided with administration roles to the PROOF
OF CONCEPT back-end, and the GUI is determined by both the business rules they set (user
eligibility and process) and the web services they require (reporting and data transfer and
validation).
The Service Owner model is driven by the development of a simple Service Owner Taxonomy,
managed and implemented by the central team (Shared Services) responsible for driving the
service front-end. It contains:
•
•
•
•
•
•
•
Service Title
Short Service Description
Service Eligibility Requirements
Service Outcome for User
Service Booking Availability
Service Location
Preferred Support Contact
DCC Proof of Concept and Case Study – 17 March 2014
Page 14 of 45
WHAT WE CAME UP WITH
THE SERVICE SYSTEM INNOVATION
A digital product is one thing; a digital product sitting within a service system is the ideal.
DCC Proof of Concept and Case Study – 17 March 2014
Page 15 of 45
DCC Proof of Concept and Case Study – 17 March 2014
Page 16 of 45
Within Road User Services the requirement of booking-and-payment only occurs for booking a driving test. This represents about, 4,000 transaction per year, compared to
60,000 licence renewals. That said roughly 90% of all Canberra Connect shopfront transactions are transport and road safety business.
From the background research, user research with stakeholders, including Canberra Connect frontline staff and call centre representatives, and a range of users and
potential users within Canberra we have captured a current state view of the booking and payment system, and a desired booking and payment service.
Current Service System
Who’s involved – service user typologies
During the research with ACT Government stakeholders we asked them to describe the types of
users. There are six potential external users from a Service Delivery perspective (ordered by the
level of involvement/effort Canberra Connect or the Call Centre has in dealing with them):
1.
2.
3.
4.
5.
6.
International People – e.g. diplomats
Students
International Students (as a subset of students as opposed to International People)
Locals, ACT residents
Federal Government Transfers from interstate (Dept of Defence a large representation
Parents (as the main transactional facilitator (payment, car owner, transporter to test)
The following breakdown of user types is based on people types who emerged from the research.
They relate to the expectations, behaviours and motivations when a user is using an online
government service for booking and paying.
It is important to think of the user typologies as representations of service experience and
motivation. This means they are types of users of a booking and paying digital service.
Furthermore, this means that the above potential customers are represented below as a type of
digital user, as opposed to demographic description.
There are two key service users groups
1.
2.
External (those who book and pay)
Internal (those who ensure the booking and payment service is delivered) including
stakeholders who facilitate the availability of the service itself.
External User
Arthur the
Assisted
What I Need
“Assist and
support me
because I’m
learning every
time.”
Stephanie the
Supported
“I know what I
need, make it
available in the
channel I
choose.”
Irene the
Independent
“I know what I
need, I expect
it online, make
it easy for me
to get it.”
How I interact with the service
• I’m confident online but not competent at online
(govt) transactions.
• I assume phone support (talking to people) is part of
the online experience.
• I use logic, not intuition.
• My patterns of transacting are set but online isn’t my
default.
• I mix channels and products easily.
• I’m capable, aware but not always trusting of
government transactions exclusively online.
• I assume the govt service will be different and that I
need to adapt from my common steps.
• I consider support to be for complex matters and will
move to a different channel for that (phone / face to
face).
• My patterns of transacting are set.
• I mix multi-channels and products easily.
• I’m capable, aware and trusting of government
transactions exclusively online.
• If the govt service is different and I need to adapt
when I expect common steps, I get frustrated.
• I like interactive, online support as part of the online
experience (e.g. live chat).
DCC Proof of Concept and Case Study – 17 March 2014
Page 17 of 45
Internal User
Owen the
Operations
Manager
What I’m Trying
to Achieve
“I ensure those
requiring a licence
test can be
assessed.”
Larry the
Licence
Examiner
“I assess all drivers
and potential
drivers who are
required to or
choose to take a
licence
examination.”
Sheila the
Shopfront
Worker
“I support
customers to reach
an outcome whilst
ensuring my
internal client
service levels are
met.”
Internal
Stakeholder
Service Owner
Directorate
IT Support
How I interact with the service
• I ensure the resources of the Government are used
appropriately whilst meeting customer need.
• I support people to meet their obligations by
having staff who are trained in ensuring eligibility is
met as per the regulatory framework.
• As the ‘Service Owner’ for licence tests, I form part
of an overall Road User Services offering to those
with cars or using private transport options.
• I ensure people who present for a licence
examination are eligible to undertake the test.
• I provide an assessment in a balanced and
professional way in line with regulatory and bestpractice expectations.
• I make sure I am available at a choice of locations
to provide for customer preferences.
• I support customers to meet their obligations in
booking and paying for a licence examination in a
face-to-face setting.
• I ensure all regulatory obligations such as proof of
identity are understood by the customer.
• I take payment and in doing so confirm the
booking time for the licence examination.
What I am Trying to Achieve
• Customer need is met by providing responsive, flexible options within the
boundaries of regulatory requirements.
• Providing channel of choice for my customers that ensures the service is
delivered in the most appropriate way.
• Ensuring licence testing, as one of many services of Road User Services,
is integrated within our total service offering for a consistent service
experience.
• Bringing best-practice ICT implementations that support customer need
and business outcomes.
• Ensuring the delivery of sustainable systems in terms of access,
reliability and useability.
• Balancing the needs of specific services like licence testing with the
broader online service offering of RUS and JACS.
Shared Services
and RUS IT
Outcome
Stakeholders
• The continued integration of the individual Directorate’s service offering
with broader one-government experiences.
• Ensuring services are delivered within the constraints of the current
operating environment (efficient).
• Looking for constant service innovation that combines a customer-centric
approach with the business goals of my Directorate.
Directorate
Leadership
DCC Proof of Concept and Case Study – 17 March 2014
Page 18 of 45
Service system innovation – a ‘Digital First’ Integrated Service System
Taking what we’ve learned about users – both internal and external - this Future Experience
Framework represents how the external user will interact with the Service System.
DCC Proof of Concept and Case Study – 17 March 2014
Page 19 of 45
HOW WE GOT THERE
THE DIGITAL CANBERRA CHALLENGE
CASE STUDY
DCC Proof of Concept and Case Study – 17 March 2014
Page 20 of 45
OUR APPROACH
“Improving the experience of people booking
ACT Government services digitally.”
by understanding and designing a service solution based
on user need and organisational capability.
When we were given the chance to compete in the inaugural Digital Canberra Challenge, we
knew that bringing our expertise and experience as service designers and multi-disciplinary
collaborators offered a unique opportunity for practical innovation.
Through understanding all the elements in play in the service system service design shows what
customers actually do and use, and how their thinking informs and influences their behaviour–
and their willingness or ability to use a service.
As service designers we believe that a product solution alone won’t build a sustainable outcome.
Too many Government products and services are implemented and offered to the public without
enough thought of users and the capability of the public service to support the service
sustainably.
Interaction with, and an understanding of, what the product provides (more time, better
understanding, convenience) is critical to the delivery of a customer experience. And great
service – where people come back for more – is about a great customer experience.
User needs and expectations aren’t standardised. But through our approach to the Challenge we
will offer the opportunity to both define them as they apply to the potential solution and make
sense of them in order to support the ACT Government making strong business decisions about
service into the future.
In order to deliver on a solution to the Challenge from a service design perspective we set out
to:
1.
Understand ACT Government Services – What are the services currently offered across
the ACT Government and how do they form a service offering?
2.
Define Good Online Booking Experiences – What stands out as excellent booking
experiences and why are they considered that?
3.
Understand the System-In-Use – Who are using services currently, how do they book
them, why do they book them and what are the outcomes and expectations of the
service recipient?
4.
Define the ACT Government Capability – Development of a digital service will only be
successful if we understand the service providers ability to host, support, iterate,
integrate and evolve the service into the future.
5.
Design a Digital Solution – Taking all of the areas above into account we prototype,
iterate and test potential solutions with users, culminating in the development of a Proof
of Concept (POC).
DCC Proof of Concept and Case Study – 17 March 2014
Page 21 of 45
Our Team
To undertake this work within the necessary constraints of the Digital Challenge, we put together
a team that has delivered a high quality and comprehensive solution that will be easily
implementable and leave a legacy of knowledge for the ACT Government to utilise.
Justin Barrie and Mel Edwards
from Design Manager Australia
(DMA) are leading public sector
service designers. As Leads for
the Project they brought not only
deep service design experience
but a knowledge of the Canberra
culture and population.
David More is an experienced
information experience and
design consultant with a
specialisation in user-centred
design, human computer
interaction and interface
design and prototyping.
James Peek is well–known
Canberra digital strategist and
developer with over 15 years
experience designing and
developing websites for small
business, large corporations and
government agencies. He
brought the “code” to the team.
Empathy is a Wellington–based design consultancy who help
private and public sector clients create better outcomes,
through design. Emma Saunders, Emilie Fetscher, Charles
Smart and Jeks Eastwick from Empathy brought a different
design perspective from a similar city (Wellington) in which the
service will be delivered.
Each of the team members are gave their time in the spirit of the competition, happy to use the
Challenge to not only develop a potential solution but to embark on digital collaboration in order
to make meaningful change for the ACT community.
Our ACT Government Collaborators
Justice and Community Safety Directorate (JACS)
•
•
Melissa Tierney
David Snowdon
Road User Services
•
•
•
•
•
•
Brett Swale – Manager Road User Services
Leanne Woolfe – Training Supervisor
Frances Stanford – Business Support Manager
Haley Eastman - Road User Services
Neil Klee - Senior BA
Werner Kruger - IT Team
DCC Proof of Concept and Case Study – 17 March 2014
Page 22 of 45
Canberra Connect
•
•
•
•
Annette Folkard – Team Leader
Chloe Anderson – Customer Service Officer Contact Centre
Stephen Coling – Customer Service Officer Shopfront
Jerome Freestone – Business Development Manager, Canberra Connect (email
discussion and phone)
Our NICTA Collaborators
•
•
Michael Phillips – eGov Cluster
Ana Belgun – eGov Cluster
What we did
Phase
Activity
Milestone
Week 1-3
• Desk research of services.
• Interviews with up to five ACT
government representatives to
understand service approach.
• Digital Service Blueprint
• Brainstorm session of service
experiences.
• Analysis of key elements of the
services.
• Analysis of a NZ case study (via
Empathy).
• Service Design Principles
• Analysis of CanberraConnect and
other ACTPS service data.
• 8 x ethnographically-based longform (1 to 1.5 hours) interviews
with people from the ACT, 3 x
interviews with Wellington-based
new drivers.
• ACT Government Services
Experience Map
• Interview with and associated
technical subject matter experts.
• Technology requirements and
capability analysis.
• Solution Implementation
Architecture
• 1st round Prototypes.
• Iteration 1 – test evaluate
workshop (with users).
• 2nd round Prototypes.
• Workshop with 4 users and 2 ACT
Government representatives.
• Final Proof of Concept.
• Proof of Concept and Final
Case Study Report
Understanding
ACT Government
Services
Week 2-3
Defining Good
Online Booking
Experiences
Week 4-6
Understanding
the System–In–
Use
Week 6-7
Defining the ACT
Government
Capability
Week 8-12
Solution Design
DCC Proof of Concept and Case Study – 17 March 2014
Page 23 of 45
How we did it - Our service design approach in focus
Undertaking Field Research where we used ethnographically based research techniques
to understand users in their own setting. We did this by combining a rich facilitated
dialogue with formal activities like card sorts and supported product testing. With users we
explored
•
•
•
•
•
What kinds of things people do online.
Interactions people have had with ACT government online.
Explore the types of transactional activities people might do online.
How people feel about things and their expectations when they transact online.
Top three things people expected/loved in dealing with ACT government online
This led not only to the development of the user typologies and features of the prototypes,
but also allowed us to balance the internal view around “What Users Want”.
Why? Because in the design an deployment of products and services (including digital), if
you don’t research directly with users, you can never gather the evidence required for
critical decision making later in the process.
DCC Proof of Concept and Case Study – 17 March 2014
Page 24 of 45
Engaging Subject Matter Experts by identifying the critical business owners at a strategy
and operational level of the service being delivered. We explored with internal users:
• How processes and systems work.
• Internal perception is of the customer experience – including most common issues and
patterns of interaction by phone, face-to-face.
• Detail of the booking and payment process – specifically the Driving Assessment Test:
o
o
o
o
What triggers it?
Who’s involved? How?
What about payment, changes to appointments?
What is similar in terms of booking and payment at the same time?
This enriched our understanding of the system in use and also allowed us to start exploring
the possibilities for an innovative but sustainable proof of concept.
Why? Because the expertise of those operating the system (from strategists and business
owners through to critical customer facing staff) should be harnessed and built in to even
the most ‘blue sky’ design activity.
DCC Proof of Concept and Case Study – 17 March 2014
Page 25 of 45
Prototyping with everyone in the service system through facilitated workshops and
managed iteration involving both users and service delivery representatives.
This led to a number of iterations of the digital product, building on the research base we
already had.
Why? Because it’s important for users to mentally and physically interact with potential
solutions as well as the subject matter experts who will deliver them in order to explore
the insights gathered during the research phase.
Utilising the skills of a multi-disciplinary team that brings together the range of skills
necessary to deliver innovative solutions within the complex boundaries of government
service delivery.
This meant we has a range of design voices to balance with our voices of the user and
voices of experience.
Why? Because a digital innovation requires design at a service, product, interaction and
experience level and all of those design approaches are critical to a quality outcome.
DCC Proof of Concept and Case Study – 17 March 2014
Page 26 of 45
What we did in New Zealand – In focus
Due to the collaborative process, the insights gathered in the development of the Wellington
Case Study were folded into the proof of concept development. Captured by our team at
Empathy the NZ perspective is drawn out here in total to ensure the knowledge gained through
the process is represented.
Reflection on New Zealand driver licensing process
It has been a while since any of the Empathy team got their licence, so we began by learning
about the process. If we’re going to talk to people about getting their licence, and help to design
a great licence book-and-pay service, we need to understand the licensing process. We sketched
it into a quick hand-drawn visual - a great way to capture a customer journey for easy reflection
later.
This task was also important in allowing us to explore the way online book-and-pay systems are
currently used within the driver licensing process in New Zealand.
Some of our key learnings from this task included:
•
•
•
•
•
•
The stages of getting a full driver licence
(learner licence, restricted licence, full
licence).
The tests required to get a full driver licence
(a mix of theory tests, practical tests, and
vision tests).
That, unlike in ACT, the process of getting a
driver licence is not often connected with
schooling.
That the New Zealand Transport Agency,
who is responsible for driver licensing,
outsources driver testing to three private
sector agents.
That the online channel is an option for
people booking and paying for the test for their restricted licence, but not for the leaner
licence.
That online bookings are made through the NZTA website, even though the agents will
administer the tests.
Reflection on booking Wellington City Council
and New Zealand Government services
Next, we investigated the way in which various local
and central government services can be booked and
paid by Wellingtonians. We mapped the various
processes in a quick hand-drawn sketch. No point in
spending hours on documentation when there is
important design work to be done.
We learned that, actually, not many services can be
booked and paid for online. Where online booking is
enabled, the process often involves simply filling out
an online form and waiting for a response.
Need-finding interviews with Wellington learner-drivers
In New Zealand, the experience of learning to drive and getting a licence is not incorporated into
the school system. We learned from initial conversations with people that learner drivers are
often secretive about the process, and that taking their test is a really big deal.
We sensed that learner drivers in New Zealand have a very specific mindset at the time of
booking their test, particularly teenagers. As such, we wanted to focus on involving people
(potential users of the system) who are in the progress of getting their full driver licence.
DCC Proof of Concept and Case Study – 17 March 2014
Page 27 of 45
We recruited three people who are soon to take their practical and theory test for their restricted
licence. Two were teenagers, and one was in his early twenties. We conducted need-finding
interviews with them based on the broad areas covered in the interviews conducted in Canberra.
That is, we spoke to them individually for about 45 minutes each, and explored with them the
context of their lives, their hopes, their motivations, their fears, their attitudes, their behaviours
and the journey they’ve taken to date in getting their licence.
Through that process, we were able to uncover the needs they have of a driver licence booking
service and experience. Together with our Canberra-based teammates, we talked about the
similarities and differences between the needs we uncovered in each location. We fed this into
the initial solution design.
Some of our key learnings from this task included:
•
•
•
•
•
•
•
Independence is very important to our learner-drivers, and that driving is a key means
to that independence.
Our learner-drivers felt they were imposing and asking for favours when they asked
other people for rides, which they felt negative about, but that they were looking
forward to freely and happily giving rides to others and did not consider it a burden.
Getting a licence feels a little like graduating; it is something our learner-drivers felt
their parents would be proud of.
Before booking their tests, our learner-drivers wanted to feel very confident that they
would pass.
Parents are an important part of the test experience, as they are often required to get
the learner-driver and their car to and from the test site.
The process of booking a test was a serious matter; they wanted to consider options,
plan carefully and know that they had it well-organised - as one participant said, “It
needs sorting out, not just signing up”.
As such, the process of booking a test was more akin to registering for a student loan
than providing shipping details or booking a table at a restaurant.
Reflection on analogous New Zealand online book-and-pay systems
We thought about other services that New Zealanders might be able to book and pay for online.
In particular, we focused on government services or services that carry similar time pressures or
emotional stressors as a driving test. We came across a few such services, including getting a
Department of Conservation hut in our great wilderness and getting a vehicle warrant of fitness.
We mapped out the experience of booking and paying for those services online. Again, a sketch
of the process was quick to complete and provided an accessible tool for later use.
We thought about what was good and bad about those experiences, in light of what we learned
of our learner-drivers’ needs. We used our contemplation of these ‘analogous experiences’ as a
basis for designing our solution.
Some of the inspiration gained from this task
included:
•
•
•
•
•
It might be good to enable those
booking tests to scan through diaries
of available test times, rather than
simply offer the next available date
and time, so that the booker can
explore options.
It might be good to provide
confirmation of booking on screen and
via email, to provide confidence that
the booking is secure and that the booker has the right details.
Those booking tests may not want to have an online account with the book-and-pay
system; especially as they might be treating it as a one-off transaction.
It might be good to reinforce the positive feelings associated with this important
milestone, whilst providing confidence that the job of booking has been done and done
well (i.e. positive but not flippant).
That it might be good to enable those booking tests to share the booking details with
those who will help them attend the booking.
DCC Proof of Concept and Case Study – 17 March 2014
Page 28 of 45
Prototype testing and iteration with Wellington learner-drivers
Once the full cross-Tasman team had developed our initial prototype, we tested it with
Wellington learner-drivers. We used the prototype concept as a tool for a further conversation
about their needs and behaviours. And we explored the ways in which the prototype solution
was meeting their needs, and how it could be improved.
We used the low-fidelity screen mock-ups, printed on paper and stuck onto phones to run
through the prototype. We know from experience that lo-fi prototypes are crucial at this stage.
The more polished a prototype, the more ‘finished’ it seems, and the less likely people are to tell
you what’s wrong with it. Because we wanted people to prod and poke it, tell us where it isn’t
great and help us to improve it, we knew lo-fi was the way to go.
Many of the findings from the Wellington prototype testing session supported the findings of
Canberra. Some seemed to contrast. Because, as with the Canberra team, we dug deeply during
our conversations with learner-drivers and in the collaborative conversations with the full team,
we were able to understand what was sitting behind the differences. It seems that the way in
which driver training and testing is linked with school in Canberra but not in Wellington makes a
big difference to some aspects of the learner-driver’s mindset.
Some of our key learnings from this task included:
In common with the ACT experience
•
Our learner-drivers wouldn’t share details of their booking with friends, as they fear the
embarrassment of failure and don’t want the added pressure
•
That our learner-drivers will probably book the test themselves, and use their parent’s
credit card to pay online at the time or defer payment if the parent isn’t home at the
time of booking.
Different to the ACT experience
•
Booking and paying for a test is not something our learner-drivers would want to do ‘on
the go’; it is a serious task that they’d sit down and concentrate on. Therefore, a
solution might need to be available through a website rather than a mobile app (not
precluding a responsive design).
•
Exploring of date and time options is very important to our learner-drivers.
•
Our learner-drivers think very carefully about the day, time of day and location of their
practical test, as they want to minimise amount of traffic on the road at the time.
DCC Proof of Concept and Case Study – 17 March 2014
Page 29 of 45
What it was like – Our team reflection on the Challenge process
DMA set out to build a deliberately diverse design team
This meant we could not only bring together key digital skills such as David with his interaction /
UX background and James with his digital strategy / development experience, but that we could
also collaborate with other designers – in this case Empathy from NZ. Our insistence on having
Empathy as part of the team was based on two factors.
1. For the Challenge we wanted to bring a wider view than just “Canberra Licence booking”.
We are always looking for the best possible thinking. We take our role as global leaders in
public sector service design seriously and part of that is having a wider-world view than
just where we live. Empathy helped us compare and contrast service systems which we
believe has led to better outcomes for the client.
2. The other factor was that because of the nature of the challenge we could actually
experiment with design partners. We know the team at Empathy well and have been
looking for an opportunity to collaborate. The Digital Challenge presented that opportunity
as we had a topic and outcome, but were not dependent on procurement, client wishes or
‘process’ to guide whether we could bring on a collaborator or not.
As David More reflected:
“It’s been a pleasure working in a team of designers (not as the sole designer in a team) and
with people of such drive, perception, creativity and discipline. It’s given me fresh energy.
A competition entry is judged on its quality and potential as well as the dull virtues of project
delivery. That again is inspiring, and has lifted this experience high above the mundane.
I’m usually intimately involved in stakeholder and user research. This time I was more distant
from it, and I was fascinated at the difference that distance made to the resolution of the
design. It placed a premium on my trust in the team’s discoveries and insights, and
highlighted just how important it is to have a disciplined, evidence-based, methodical, and
sober approach to design decision-making.
My own instincts and assumptions could not guide the refinement of the design, and much of
the pleasure of this experience has derived from recognising the quality of the research and
the critiques provided by the team. It’s another lesson, as if one was needed, that
‘truthiness’ and arrogance are pathways to delusion. Useful design, what will be, emerges
from humble appreciation of what is; whatever we might wish otherwise.”
We focused on a digital product as the starting point, not the end state
As service designers we are often engaged to look at a particular element of an overall service
(such as ‘a database’, or ‘touchpoint’) and we immediately start to shift our client from
‘touchpoint’ to ‘service’ because the service system is what enables touchpoints to support
customers and business to achieve their goals and outcomes. Our role is to always engage at
the service level and provide service-based insights to the client, regardless of what specific
question they engaged us for at the start of the project.
With the Digital Challenge, because we had to be careful with scope creep and the amount of
time we put in on the Challenge, we allowed ourselves to be much more focused about the
digital product. It’s true that because of the way we worked we have ended up with a range of
service innovations, but a digital product focus allowed us to:
•
•
•
Undertake user interviews with a significant product/feature testing approach rather
than a more holistic experiential-based exploration.
Make the user prototyping workshops less about concept exploration and more about
product testing than we normally would.
Engage specific build disciplines in our team (James in a developer role and David in an
interaction design role).
Empathy also had reflections on the different approach for this challenge, particularly in relation
to prototyping:
“We were able to prototype our process and relationships.
DCC Proof of Concept and Case Study – 17 March 2014
Page 30 of 45
We took this challenge seriously, and made sure we did a good job and built a sound
solution. But knowing that we were competition challengers, rather than consultants being
paid a lot of money to perform our services, meant that we felt a little more free to prototype
the way we work.
Prototyping is critical to the process of design, and we build it in to every solution we create. On
this project, we were able to take that further. We loved being able to develop and test new
tools, new techniques, new relationships, and new ways of collaborating in our roles. We’re
stronger designers for it, and have a proven model for trans-Tasman design collaboration.”
We investigated multiple jurisdictions at once
In our service design projects we would always scan the international environment in order to
understand best practice approaches that might be applied, in this project we were able top that
by running a parallel design investigation in Wellington, NZ.
This is exciting for us for a number of reasons:
•
•
•
Wellington and Canberra have similar traits in terms of their role and place as a city
(though they are very different places).
The opportunity to work with like-minded designers with different approaches meant we
would move from a collegial relationship to collaborative partnership with Empathy –
firing both sides of the Tasman up.
We were able to support our notion that we should look far and wide for inspiration and
insight and that just because we are undertaking design for a small city in Australia,
doesn’t mean we should confine ourselves to only thinking about Canberra.
This experience was also important for Empathy:
“We learned key differences between ACT and Wellington learner-drivers, and were reminded
that context is everything.
In design, empathy is key. We have to understand the attitudes, motivations and situations
of people we’re to create services that truly make a positive difference in their lives. Gaining
empathy for another person is often about understanding our differences more than our
similarities. The differences can’t be assumed. Through this challenge, we learned that
learner-drivers in ACT and Wellington feel quite differently about preparing for, booking and
sitting their driver licence test. We learned that the cause of those differences is largely
context; that the licensing process is heavily tied to the school system in ACT, and not in
Wellington. It is a great reminder and case study in the way that context or situation shapes
motivations, attitudes, fears and behaviours. Context is everything.”
The Client relationship
We got to work with a client, Road User Services, as a collaborator in the competition rather
than a pure client. As an established design agency, we tried to set the client at ease by utilising
our proven design methodology and tools. We immediately applied the same discipline as we
would a ‘normal’ project by developing a formal Intent and Scope and reporting continually
throughout the life of the challenge.
During the challenge we were given unfettered access to anyone in Road User Services we
needed to talk to or collaborate with. We were also extremely pleased that both Road User
Services and Canberra Connect staff were allowed to join in our prototyping workshop, a critical
component of true service design. We know the representatives from the two areas both
enjoyed being allowed to collaborate with the users of their services as well.
Perhaps the only constraint on the client relationship was the Challenge topic itself. Under no
circumstances is the digitisation of booking and payment of licence tests a high priority for Road
User Services. The number of tests and the largely natural process for booking that exists now
means that there are many other opportunities for digital innovation that would serve the
business better.
Knowing this meant that we were engaging with subject matter experts on a subject that didn’t
necessarily have a big impact on their business. That said, we were delighted that while the RUS
team may have been thinking “what are these guys even looking at this for” they never said that
DCC Proof of Concept and Case Study – 17 March 2014
Page 31 of 45
out loud and went out of their way to support the work we had been asked to do. We hope, in
return for their support, the detailed design this document represents gives the team a platform
of evidence to build their future decisions on.
We had the key business objectives and business explained to us, were taken through the
training and support systems for the service delivery group, were given access to all available
data around service use and satisfaction and were briefed on all aspects of the technical system.
Without this support we would have had no context to balance what we were hearing from users.
We thank the team, RUS Manager Brett Swale in particular, and the Executives who brokered
access to the team, Melissa Tierney and David Snowdon - for the support.
What was it like – Reflections on the Challenge itself
When we put in a submission to be one of the teams in the Digital Challenge, we knew we were
taking ourselves out of our normal business approach – it was one of the drivers for us being
interested in being involved.
We also wanted to reinforce, as we noted in our submission, that digital solutions in the absence
of a service design approach are not really solutions, just products waiting for a user group. For
that reason we were excited that the Program Board chose us to compete.
Our reflections on the actual ‘project’ we undertook are above and thematically weaved
throughout this whole document, but in terms of the Challenge as a competition, we would
reflect on the following when asked “what was being a part of the challenge like”:
• Being given access to key ACT Government contacts was a major win
From the initial pitch of our submission, right through to the pitch of our solution, we have
been given amazing access to ACT Government Executives and key subject matter experts.
As a business trying to pull off a paid project, this kind of access would take months to
broker and then be bound by all kinds of procurement and process red tape. The access
afforded to not only work on a solution rapidly, but be able to tell our story about the
importance of service design has been an outstanding experience and we congratulate
NICTA for establishing this approach.
• The ‘Competition’ isn’t quite a ‘competition’
The make up of the Challenge as a competition works as a marketing construct but there
are too many variables for it to really be competitive. In order for it to be a true competition
we would recommend:
• Both teams being given the same challenge. If the purpose is to judge the best digital
innovation then it should be able to be benchmarked against the other entry. This would
also mitigate any feeling that the Government was using the competition to get ‘twice as
many’ solutions built by the innovation community.
• Like teams should be put up against each other. Having a professional design agency up
against a newly formed tech company looks good on paper, but it might aid the
competition to have start-up’s against each other and agencies against each other, so that
elements of the competition such as mentoring and guidance are within the context of the
competitors requirements. This could also foster greater promotion of the competition as it
would build tension that could be marketed in wider professional groups (much like the
success of the Gruen Transfer pitch segment, which gets it’s life from agency pride against
similar kinds of competitors).
• Use the prize money to seed the competition activity. The opportunity for the Challengers
to make the most of being part of the Challenge – whether they win or not - is reward
enough. The significant time commitment expected and committed for no financial
acknowledgement until the end, could be better addressed up front through initial seed
funding.
Empathy provided the following reflections on the Challenge from their perspective:
• We have a showpiece for potential clients
We can’t always talk about the work that we do. It is often confidential, sometimes highly
commercially sensitive. Because this project is part of a public competition, we’ll be able to
use our process and solution as a case study for prospective clients. Not only will it help us
to explain the way we work, we’ll be able to show off our solution and prove that we work
effectively as a trans-Tasman team.
DCC Proof of Concept and Case Study – 17 March 2014
Page 32 of 45
APPENDIX 1 – WORKFLOWS
Pathway for booking and payment
Pathway for booking completed and paid online
DCC Proof of Concept and Case Study – 17 March 2014
Page 33 of 45
Pathway for incomplete booking with payment deferred
Pathway for making deferred payment
DCC Proof of Concept and Case Study – 17 March 2014
Page 34 of 45
Pathway for changing date or time of a completed booking
DCC Proof of Concept and Case Study – 17 March 2014
Page 35 of 45
APPENDIX 2 - WIREFRAMES
DCC Proof of Concept and Case Study – 17 March 2014
Page 36 of 45
DCC Proof of Concept and Case Study – 17 March 2014
Page 37 of 45
DCC Proof of Concept and Case Study – 17 March 2014
Page 38 of 45
DCC Proof of Concept and Case Study – 17 March 2014
Page 39 of 45
DCC Proof of Concept and Case Study – 17 March 2014
Page 40 of 45
DCC Proof of Concept and Case Study – 17 March 2014
Page 41 of 45
DCC Proof of Concept and Case Study – 17 March 2014
Page 42 of 45
DCC Proof of Concept and Case Study – 17 March 2014
Page 43 of 45
DCC Proof of Concept and Case Study – 17 March 2014
Page 44 of 45
DCC Proof of Concept and Case Study – 17 March 2014
Page 45 of 45