top of page

Our Brief

CFA%20Title_edited.jpg

Communicating with people in government

This was a team project with myself, Claire Gee and Rebekah Mifsud.

 

Within three weeks we worked with Code for Australia, a civic tech company, to find out how well their current website was communicating their message and services to public sector leaders. Their focus is on their program called “The Fellowship” which sends a team of three technologists to work within a government department for six months helping them to rapidly uncover potential problems and solutions. We also were tasked with looking at what useful resources could be provided as a first step in communicating with prospective clients.

The Team 

Rebekah%2520Mifusud_edited_edited.jpg

Rebekah Mifsud

Jonathan%20Broome_edited.jpg

Jonathan Broome

Claire%20Gee_edited.jpg

Claire  Gee

The Design Process

PROBLEM ?

SOLUTION !

PROBLEM

STATEMENT

DISCOVERY

SYNTHESIS

DEVELOP

DELIVER

DISCOVERY

The Challenges

- Define Code for Australia’s role in the civic tech field.

 

- What was Code for Australia’s goal in getting help from UX Designers? 

 

- Who were their target users and would we have access to them for our research?

- The language of government systems can be quite dry. This project required a lot of research to really help get our heads around the problem.​

Discovery
Overview

BUSINESS RESEARCH

First we need to understand who our client is.

According to them, they are a civic tech company.

This was the first time for me to see this term.

What is civic tech? 

 

According to Wikipedia: “Civic technology, or civic tech for short, is technology that enables engagement, participation or enhances the relationship between the people and government by enhancing citizen communications and public decision, improving government delivery of service, and infrastructure”.

 

There are various types within this field, but the main takeaway is they are working within a framework that enables processes to move faster and more efficiently than were previously possible. So it’s actually the UX Agile process which Code for Australia mentions on their website.

Business Research

STAKEHOLDER INTERVIEWS

From our first assumption about the area they operated in we then had an interview with the managing director first and then a second one with one of the founders. This is because we wanted to see the fuller picture from different sides of the organisation.

Essentially we asked them about how they saw themselves and what their target audience was, as well as their goals and aspirations going forwards.

The key findings from our interviews were:

  • They want to challenge the status quo.

  • Their main business goal is to scale their influence.

  • They worked predominantly with state government.

  • They saw themselves as unique. “No one else is operating like us.”

  • They knew that there were challenges for government folk with their model.

  • Making relationships with people in leadership is how they have done it in the past.

Stakeholder Interviews

THE WEBSITE

This is a gallery of screenshots to give you a general feeling

of the website during our project.

Current Website

MARKET ANALYSIS

So if they are unique does that mean they have no competition?

Looking at the market we found these organisations working in this space:

CODE FOR AUSTRALIA.png
Market Analysis

USER INTERVIEWS

We were able to conduct 8 in-depth interviews. 

 

1 current Fellow 

6 government employees

1 former government employee

 

With the Fellow we asked her to share the story of her experience,

looking at what the challenges and achievements were for her.

User Interviews

Range of Interview techniques

Knowing that our target users were in government, 

we gave a survey to previous partners of Code for Australia.

We also conducted some interviews in person,

as well as some video/phone calls.

 

For all the government folk we asked:

What were the budget and regulatory constraints?

How were decisions were made in their department?

What information would decision makers need to see?

How did they prefer to get in touch with organisations?

Market Analysis by Users

Our interviewees identified to us who they would use if not Code for Australia:

CODE FOR AUSTRALIA (1).png
Image 11.jpg

USABILITY STUDY

From 5 government folk who had never visited the website we asked them to have look at it. We screen recorded their interactions with it as well as listened to their process to get to the information they needed to make a choice in working with Code for Australia.

Contextual Enquiry

SYNTHESIS

Abundant information was gathered from our surveys and interviews.

So how do we organise this and how should we present it?

Synthesis

DATA VISUALISATION

One of questions we asked everyone was to say, in 30 seconds, 

three words they associated with Code for Australia.

Visually representing data is a great way to hone in on trends.

Here is a clustered bubble chart with size and proximity being good cues to what is important

Impressions from Previous Clients

Data Visualization

Defining It

We went into creating an Affinity Map

to really define the problem and solution.

Several areas were drawn to our attention.

Gov Process + Expect.jpg

Government Expectations and Process

“I’ve got a problem to solve, I want someone to help me solve it”

Affinity Mapping

Behaviour

Follow standard procedures.

Work within Gov. timelines.

Try to convince people to try something new.

Have to consider regulatory frameworks and Data security. 

Look for workarounds in procurement.

Look for proven case studies on how things could be different

Goals & Motivations

Want to be forward thinking/change processes.

Want to make Gov. better for people.

Want to prove Code for Australia are legitimate and will deliver, they need evidence to prove this.

They are motivated by other people’s stories, or a trusted colleagues advice.

Frustrations/Pain points

Leaders may not be on board (not forward thinking)

Procurement process and restriction.

Slow pace of change, Slow Government.

Need to work within governance and auditing restrictions.

Need to consider information security

Have to work within allocated budget.

Have to predict the solution, before they can get budget.

A Persona was developed to keep the focus clear

PERSONA

Government Innovator

They have learned about Code for Australia from a colleague.
They want a more modern process, want to work differently - they are tech savvy.
They don't get the final decision on bringing in change makers, but they have a chance to influence it.

Persona

Journey Mapping

This is a tool that was essential to plot the user's journey from their initial moment of discovery about Code for Australia through the long process of government requirements and  into working with them.

Miro Journey Map.png
Journey Mapping

SWOT ANALYSIS

It's important to recognise what is currently happening and what the future may hold.

SWOT Analysis

Strengths

  • People felt the site looked professional and clean

  • People familiar with them were overwhelmingly positive.

  • Once they understood the values and intentions users were encouraged and positive.

Weaknesses

  • Everyone was confused by the navigation and menu items

  • The language on the website is frustrating users. They want something more straightforward and concrete.

  • They wanted more detail in the case studies that would help them make a decision.

Threats

  • The status quo.

  • Community hostility to government spending on innovation. 

  • Some leadership mindsets are not open to change.

Opportunities

  1.         Code for Australia has worked with many different Government partners and this impresses potential clients. Keep this front and centre.

  2.         Improve the messaging around ways that organisations can taste Code for Australia before committing to a 6 month program.

PROBLEM STATEMENT

Government innovators need a way to prove the value and credibility of Code for Australia’s model so that they can start a partnership.

Problem Statement

DEVELOP

Develop

How Might We...Statements

Help government innovators find the right information about Code for Australia so they can be confident of their value and credibility?

Meet each type of concern government organisations have, with proof of how Code for Australia have managed this constraint?

Hypothesis

HYPOTHESIS

We believe that by providing easy to find and relevant information, for government innovators, we will prove the value and credibility of Code for Australia and an understanding about how to partner with them

We will know this to be true when we see an increase in government folk contacting Code for Australia to talk about partnerships.

 

INFORMATION ARCHITECTURE

5 of our interviewees completed a subsequent card sort for us.

 

This was made up of 20 cards which represented the different pages on the website.

They included the heading and first line of content.

This resulted in  grouping patterns, that we began to see emerge.

 

We based our sitemap on both this and the strong feedback we got from user interviews on the terms people were looking for in the navigation…


About us       Services        Case Studies

IA

SITEMAP

Site Map

USER FOCUS

  • Code for Australia should focus on what the target user wants, rather than focusing on what they can offer them.

 

  • Put the things that your users need straight up in front of them on the home page.

Looking at what is common practice is always helpful as one of our users pointed out:

"I think a lot of council websites do it really well...all the key stuff is on the home page and you don’t have to scroll down to find it."

Council Example.png
Deliver

DELIVER

The deliverable for this project was to show Code for Australia the story of how their users, both current and future, made choices to work with them.

Several things helped with this:

First, the words that users associated with them shown in the bubble graphs.

Second, the user journey map. This really helped them understand where the opportunities were to help their clients.
And finally we presented them with an example of how their website could look as well as a list of recommendations. 

Possible Home Page

This homepage follows the data from our card sort and subsequent site map. All important information is shown along the top, as well as an arrow giving users bread crumbs for navigation.

The background image used is actually from another of their pages. We feel that it shows better the sense of collaboration in a work place than what was previously shown.

Open CODE FOR AUSTRALIA.png

RECOMMENDATIONS

Recommendations

NEXT STEPS

  • Add breadcrumbs to the site to aid navigation.

  • Consider adding a phone number to the site.

  • Images should reflect users needs. Use photos of the team only on 'About Us' pages.

  • A PDF of the checklist for Fellowship establishment.

  • Show Gov. logos with Case studies = quick recognition.

  • Provide PDFs of case studies. These make excellent resources to share with a colleague

  • Change the Navigation and Content (as per our site map).

  • Rename the ‘Project’ page ‘Case Studies’.   

  • Have whole Case studies available on the site, no email or needed to view more.

  • Who You Are’ and ‘What You Do’ is the first thing users should see on the home page, followed by some Case Studies ( 2nd thing users look for).

  • The users want case studies with concrete info around what the challenge was and how the solution was delivered.

  • Create a Case Study about how to set up a Fellowship with a government partner.

  • Create a checklist of government barriers and talk about how you can work with Gov. partners for each item. This acknowledgement will encourage confidence.

  • Very clear guidelines regarding onboarding on the Gov. side should be written to combat misalignment of expectations.

  • Create content talking directly about how Gov. Orgs. could get a ‘taste’ of Code for Australia.

Final Thoughts

This project was very challenging with the amount of detail required to first identify the situation and then grasp the different processes involved when a user makes a decision. Also knowing what was important to show the client in our presentation was necessary, in keeping the process clearly defined. Fortunately our stakeholder was happy with our findings and they have

 started to put some of our recommendations to use.

 

If you read this far, then thank-you for your time!

Final Thoughts
bottom of page