Case Study #2 (Problem Solving)

Case Study #2 (Problem Solving)

18 October 2023

Summary

Giki Zero is an employee engagement platform that allows staff to calculate their individual carbon footprint and take sustainable steps to lower it. Often, challenges are run where users can compete to see who can take the most steps. Below is an example of one of the many design solutions I was responsible for implementing on this product.

Previously, the only way to join a team was through the Join Teams page which users would often ignore. To try and resolve this, Giki introduced a ‘compulsory teams’ setting that would force a user onto the Join Teams page where a user would then need to select their team before they could access any other Pro functionality on the platform. The problem here was that users would often join the wrong team or none at all and then stop engaging with the platform altogether. They had also tested various ideas such as introducing this during the onboarding process or as a pop up which all failed to solve the problem. This was identified through the complaints of admin users and backed up by data.

I was tasked to resolve this issue and to find a way that would get users into the correct team without interfering with the users engagement.

A UI representation of the design solution implemented on the website

Problem Statement

As an organisation, I want users sorted into their correct teams because they currently aren’t joining when prompted.

Approach

My first task was to break down the problem statement into the different issues that would need to be solved as part of this project. This required defining the type of users that were likely to be impacted by this problem, developing user personas with the needs and requirements of each.

My next task was to carry out market research on platforms that have similar functionality. This led me to discover that, in the vast majority of cases, the assignment of teams is the responsibility of an admin user and not the user themselves which played a large role in changing the spec.

By updating the problem statement, I was able to establish control over the team assignment, as well as keeping with the original requirements by not interfering with user engagement and simplifying the problem breakdown:

The Giki Zero user flow diagram for the product

In order to assign new users to a team, I reviewed the user flow to establish the best place for these updates to feature and referred to the engineering team to find out any limitations before testing wireframe concepts with existing admin users where users would be assigned a team at the invitation stage. I also tested ways for admin users to edit and assign teams to existing users before settling on the agreed solution below:

A visual representation of the high-fidelity wireframe concepts we used for testing

Some of the feedback we recieved from test users proved very useful leading me to implement search functionality within the teams dropdown menus. It also pointed out that pagination limited the ability to filter only 10 unassigned users at a time which led to me implementing a filter to increase or decrease the pagination limit.

Timescale

Research: 1 week User personas: 1 day User flow: 1 day Wireframes: 2 weeks Gathering and implementing feedback: 1 week UI Designs: 1 week

Results

After implementing the signed off designs there was a significant decrease in the number of users not assigned to a team and team related complaints dropped from several times per month to zero. Client satisfaction also improved and a new potential sales opportunity was identified in which team specific challenges could now be integrated. This would allow Giki to sell challenges to individual teams within an organisation. For me the most interesting part of this experience was the research phase and learning to think outside the box and see the problem from a new perspective.