App Marketplace
Introduction
Despite what Cutover had being so revolutionary and popular with our clients, it had very low adoption rates.
Data analysis of this area identified hundreds of users visiting the page, however only a handful installed integrations for use on their runbooks.
Insights
Only 16 people created an integration in April with only 3 people in July
35 users visited the integrations screen but only 12 clicked create and 22 edited
Low usage > 100 users visiting from each client per month
The purpose of this project sought to understand the why behind this user behaviour and provide a redesign to increase adoption.
Lets jump in to see how I got there.
Research
To kick off the project I completed a “tear down” of the current experience to uncover pain points.
This was used to align the team on the current experience (view flow chart).
Problem identification exercises enabled me to uncover pain points with flow, navigation and information.
Undertaking ‘How might we’ enabled me to walk through problems from a user point of view.
Market research enabled me to assess how our competitors solve this problem.
This included assessing other apps in terms of what was good and bad, and any notable features.
Persona identification enabled me to understand the user I was designing this for.
Discussing and documenting their daily needs and challenges helped me empathise with individual users rather than groups.
Considering different personas enabled me to cater for different people, their needs and expectations.
Breaking down by these attributes, I was able to make design decisions that were user centred and brought the most value.
I undertook Use Case Mapping to understand all the capabilities I needed to design.
This was important to ensure the redesign did not upset existing user jouneys.
Defining a red route helped me to outline the priority journeys which I should cater for.
This was important to ensure the redesign did not introduce unnecessary complexity to the view, and gave me areas to focus on first.
The above research led me to devise a design brief outling the problems to be solved.
Brainstorming in FigJam enabled me to collaborate on ideas to solve the user problems highlighted in earlier ‘define’ sessions.
Putting ideas into a Value vs Effort matrix enabled me to prioritise features.
I gathered up those in ‘Low effort’ and ‘High value’ quadrant and reviewed those in other sections.
Design
Low fidelity wireframes enabled me to iterate fast.
This helped me to organise the high level information and communicate the big ideas to stakeholders with little effort.
I looked to our design system to ensure I had all the necessary components.
To build consistency into the product I tried to repeat existing patterns and use existing components the users were familiar with.
High fidelity mockups brought my ideas to life.
Prototype
Reflection
User Initiative
Witnessing engineering teams embrace this projects investigation, and our thorough user research shaping the current state of the product has been gratifying. There was a notable precedent set to engage in discussions to prioritise rather than disregard any reserach or design efforts simply because they weren’t part of the initial roadmap. This openness facilitated swift progress and frequent experimentation throughout the iterative process.
Balancing Business and User Needs
Engaging business stakeholders from the outset and maintaining their involvement ensured a continuous alignment with both business objectives and user requirements over time. Yet, there’s a risk of introducing excessive change through this approach. Nevertheless, I perceived these sessions as invaluable opportunities to deepen our understanding of users, thus enabling us to infuse their perspectives into our internal deliberations. During discussions with stakeholders regarding business needs, I could effectively highlight potentially perplexing ideas, thereby managing their expectations and aiding in prioritising their challenges.