Workflow builder
Research / UX/UI / Project management

Imagine you're filling out an online request for a new bin from your local council. After you press 'Submit', where does that form go?

Context

While working for OpenCities, I was the senior designer on 2 product squads building an online form builder for local councils and governments. While the citizen experience of filling out forms was richly developed, many council workers emphasised that the admin console where they viewed those submissions wasn't powerful enough as it only allowed them to view and export the responses.

Problem

Council workers needed to be able to set automated rules to follow the business logic of the council: who should review what responses when, where should they go after approval / denial, and how quickly should requests be resolved.

Process

I worked with my product manager to set up internal staff and client stakeholder interviews so that we could gather use cases and requirements that would guide our design and its scope.

Through those interviews, we learned that our government clients had 2 audiences that they needed help managing requests for:

requests from citizens
requests from internal staff

Taking those use cases and using an early UI concept of a drag-and-drop workflow builder, we paper prototyped various types of requests and their possible workflows, defining the properties and logic we would use for steps and their resulting transitions.

Permit requests - new, renewal and cancellations.png

The early prototypes and use cases helped me, engineers and our product manager map out the scope of workflow features through multiple phases. We identified early impacts of the feature across the app as well as future capabilities we'd need such as sending data or documents to other systems, adding in-office-only fields and digital signature approvals.

We focused our efforts on completing the workflow builder, a drag-and-drop interface with overlay modals that expose settings where form authors can define the logic for how responses move through a workflow approval process, configure which staff members should be able to review the responses and determine when to send notifications.

Once we had defined the capabilities and limits of the workflow configuration, we turned our attention to the Review Center, a new area in the product where government staff members who were assigned as reviewers via the drag-and-drop workflow builder would then be able to view and action the responses in steps they were assigned to manage. I took cues from email inboxes and Zendesk's support ticketing system to indicate new vs read responses and internal vs public-facing comments.

Review Centre Listing - Never Actioned Response.png

For our initial launch, we released to a select group of clients under a closed beta. During that time, I wrote the test plan and facilitated usability testing on the Review Center to ensure that, as a highly-trafficked and critical area of the product, it allows government staff to confidently and effortlessly review form responses.

After each task, test participants were asked to rate the ease of each task, allowing me to map out the areas of frustration and efficiency along the way. Analyzing the results across testers showed clear areas where we could refine the solution, including quick-wins like cleaning up email and system feedback content as well as clarifying a reviewer's onboarding experience before and after their first response review.