After we got approval from leadership to tackle the project, I begin by refining the problem space through research and collaboration.

1️⃣ First, I took screenshots and documented important flows in Figjam, then adding my own notes for improvement.

2️⃣ Next I held two, quick virtual brainstorming sessions using Figjam with with Customer Success.

3️⃣ Then I did a brainstorming session with our own development team.

4️⃣ Finally, I analyzed and synthesized what I found.

More than just refining problems, these sessions drove alignment on ideal outcomes across teams. It helped us to move faster since customer success had weighed in on the outcome and was invested in its success. Our development team also had a better understanding of why we were tackling the project and wanted it to be successful.

You can take a closer look at the Figjam here 🙂

There were only two pages used for set-up: “General Settings” and “UI Customization”.

“General Settings” was intended to include the minimum steps for set-up, but over time additional settings had made their way in.

“UI Customization” allowed the user to customize the two different views—the “admin” view, and the more limited “recruiter” view.

However as we added more and more settings over time, it became confusing as to which setting applied to which view.

We needed a new information architecture that would make things easier to navigate and understand.

Also, we planned to add more set-up features in the future, so my solution needed to be flexible and scalable.

So, with the help of customer success, I mapped out the ideal set-up flow:

✅ Finalizing Information architecture

After feedback, I landed giving each set-up step its own page within a first-level nav.
The basic set-up steps wouldn’t change, so the navigation would stay simple.
I changed UI Customization into View Configuration, which made it clear that this is where users could set up a view.
Each view became a sub-tab under View Configuration. This allowed us to add more views over time, and charge for them.

✅ Finalizing the new navigation

I used the using the existing navigation component. Since we wanted to reduce design and development time, this was a perfect trade-off against designing a brand-new onboarding experience from scratch.

Also, at this point onboarding and set-up was only done by customer success, so even this intermediary step would be an improvement.

The existing navigation component surfaced all steps, so users could easily follow the flow or find a step out of order and return to it.

Using an existing component also allowed me to focus on other parts of the design that were more essential, and allowed the development team to move faster.

Settings were divided into sections on a page, and each section had a large paragraph of text, multiple tooltip explainers, and links out to lengthy help articles. It was informationally dense. Moreover, did not follow best writing practices for clarity and brevity.

Using my past experience as a legal writer and best practices for writing for the web, I rewrote the explainer text for each section.

I also created a series of content writing guidelines including:

Paragraphs should have no more than 3 sentences.

Avoid jargon and product specific terms, except where it is necessary to understand what is being configured. If product specific terms are appropriate, make sure they are defined.

With the design team, we decided that tone should be informational and reliable, not too friendly or familiar, since the subject matter (pay consistency and equity) was a serious one, and we wanted users to trust us.

Assigning prioritization

I worked with the product manager and front end lead to prioritize the design work. Not everything that was designed made it to release. We prioritized based on what would give users the most self-service ability, balanced by engineering effort.

Break down into smaller chunks

Once we had decided what we would build, we broke the work into four iterative chunks with product and engineers. I created final mocks with annotations for each one so it was clear for engineering.

Final product: