Government staff take great pride in what they do. How about giving them tools to be more productive and serve their citizens better?
Government staff needed a robust way to do their work on the move. The existing solution set was fragmented across platforms and was based on legacy technology. This started becoming an organizational nightmare. With a view to unify the solution set, create a modern, seamless and delightful user experience, this project began…
- As the primary researcher, learning more insights about users and prospects
- As an interaction designer, translating learnings from research into wireframes and mockups
- As a part-time product manager, partnering with the product owner.
BEFORE PROJECT KICK-OFF
To start, in association with the entire design and product management team, the focus was to get an overall sense of where we were at and where we needed to be.
We decided to piggyback upon multiple streams of data which were readily available. I had the pleasure of participating in a few ride-along sessions with government staff, which gave me a first-hand experience of what being in their shoes felt like. Below are a few things we did pre-kickoff.
1.Product Testing at Accela’s User Conference
By testing the existing version of the apps on phone and tablet, we were able to gauge elements of the designs which worked and ones which did not.
During the event, we also took the time to test a prototype. The fundamental shift with the prototype was a new information architecture and navigation scheme. Here are a few screen shots from the event.
Products validated during user conference
2.Site Visits and Shadowing
By shadowing field staff, we were able to understand the core user journey and how they used digital and non-digital solutions to help them complete their work.
Ride along with an inspector
3.User feedback on Salesforce
Sifting through product ideas and pain points that came from customers, we were able to get a pulse of our user base.
By pruning through the list carefully and by identifying items that the biggest potential for benefiting the users, we were able to be more prudent in how we prioritized our backlog.
By looking at related and relevant apps in the domain, I was able to get a sense of what the competition did. Here is a collage of how the competitive landscape and relevant products in the domain look.
Distilling through all this feedback, we farmed the product backlog.
THE CORE USER JOURNEY
There were quirks that we had to account for, in terms of business processes, user workflows, behaviors and goals. To help us think through this, a couple of product managers and I did a sticky-note exercise to brain-dump everything we knew about our customers.
This came from having done ride alongs and knowledge that we had imbibed about our customer base. At the end of the exercise, what we ended up creating was a refined persona and holistic user journey.
To put it in a nutshell, the journey looked into various touchpoints, both digital and non-digital spanning a typical user’s day; starting the day at their office desk, to out on the road driving around, conducting work in the field to coming back in to the office to log their work.
This has served as our baseline in understanding how things work at a very high level. With iterative research, we are continuing to learn more about our users and we keep adding to this process map.
BEHIND THE SCENES
Our mobile solution does not live in isolation. It is part of an ecosystem of products, each of which serves a different need. Here is a quick run through.
- We have the Civic Platform, which is the back office product that inspectors can use to research and learn more about the work that they are doing for the current day
- Next, as IT Administrators, one could use our application Admin setup and configure the mobile app specific to each customer’s need.
- Then, we have the mobile app, which serves as the extension of the Civic Platform and allows government staff to carry their work while in the field.
- Finally, we also have the Contractor Central, which is a companion app. This is used by contractors and home owners to manage the progress of their ongoing construction projects.
This has been a hard nut to crack, given that the team has been beset with different set of challenges over the course of the project. As with any project in real life, change is the nature of the beast. Along with the product owner, design director and engineering manager, I continue to shape the scope of this effort.
- Move users off legacy technology, albeit provide new ways to help users achieve their goals
- Create an MVP, mitigating feature gaps
- Create a more seamless user experience
- Double adoption rate
- Mitigate existing user pain points
THE DEVELOPMENT PROCESS
Initially, we got too excited and rushed into the process of product development. As a result, we went into the first few sprints where product requirements were not well-rounded and we did not leave enough lead time to get feedback from developers before starting the sprints. This led to a significant confusion within the team and stymied productivity.
From the design team’s standpoint, we were hard pressed to crank out designs, which were not validated by the users or by the product team as much as we liked to. With sprint retrospectives and some feedback from within the team, we have now settled into the following process for development.
From the design team, here is the process that we have adopted.
- The design team has moved into adopting the design sprint methodology.
- I start by working with the Product Manager to hash out use cases and experience goals and work with fellow design team members to design and deliver.
- With the use cases, the team starts by creating wireframes, which are validated and then visual design takes over.
- Each feature set is validated as part of a design sprint.
From the product development standpoint, here is what we have settled into.
- Developers start by building on wireframes (which are validated with users at this stage).
- Once developers build wireframes, they move on to stories to bind the data.
- Once the design has settled down, developers complete implementing a feature set by updating the look and feel to the final visual design.
What this process has allowed do as the design team is to get user stories which are validated into sprints and also for product managers to plan out and execute a pipeline in an organized fashion.
A SNEAK PEEK
Following this section, you are going to get a sneak peek into what went into the making of a core feature; namely the job list. As you continue to follow along, you will get a first hand understanding of how
- use cases were defined.
- designs were kick-started.
- research informed the design.
- how design iterations were made in improving the features.
THE JOB LIST
Think of the app as a todo list of jobs to be done for the day. Government field staff use the list to identify
- the scope and type of work for each job.
- time and location of each job.
This was an existing feature which we wanted to improve. Following is a screenshot of the job list design from the old application.
We use a design studio to kick-start any major feature set. In this setting, we bring together the design team, product managers and developers to sketch out design solutions. This is not a design contest; rather this serves as an avenue to generate ideas and estimate the feasibility of each design against our current tech stack.
I have been taking the lead on organizing and setting the context for the studios. To give an example, I pull together top customer complaints, feature requests, any previous research insights and structure time-bound design activities. Here is an activity which I put together for the design studio on the job list feature.
Here are a few design sketches that came from the design studio. We observed the following themes across different groups that participated.
- Display information as card to give a quick summary of the scope of work.
- A dashboard – to give a summary of how the user’s day looks like.
Just to reiterate, each job had to inform
- where the job was at?
- what the scope of work is/was?
- when is it due?
List and map based views of a job were existing features. We had heard from our users that they need more information on a job than what is available on a list. This incentivized me further to explore a card based view of jobs.
CURRENTLY IN DEVELOPMENT
We recently tested during our user conference and the feedback was overwhelmingly positive. Users loved it!!
This project is currently in active development. I continue to play key roles in the design and strategic vision of the product. Feel free to reach out to me if you are interested in learning more.