Company
PagerDuty is a tool for Ops Teams. PagerDuty notifies on-call developers to quickly resolve website outages.
Prompt
Design an app store in 8 weeks for PagerDuty's growing suite of 3rd party integrations.
Goal
Help users find the PagerDuty apps that can help them most. Also, position PagerDuty as a platform, encouraging developers to build new apps.
My Role
I worked mainly with a PM and 5 developers, but received design feedback from the UX Team and Product Team.
We already had some 3rd-party apps that were quite useful, but they were buried deep within the app --->
To make apps easier to discover and install, we needed a better site structure. We needed an app store!
User Interviews
I led three user interviews, including one at Lyft HQ with a DevOps team manager. Some key takeaways:
☞ Users weren't aware of most of our 3rd party apps.
☞ When responding to a website outage, teams follow rigidly documented response protocols to ensure the situation is resolved quickly.
☞ DevOps managers were the most excited by these apps because they were charged with improving their team's response protocols.
Card Sorting
During my interviews, I used card sorting to better understand users' mental models regarding our apps. This would later improve our information architecture.
"Users spend most of their time on other sites. They prefer your site to work the same way as other sites they already know." - Jacob's Law
With my developers and PM, I helped to create prioritization matrix to decide which features would provide the most bang for our buck. As a team, we decided the key features for v1 were:
View popular apps
View app categories
Search for app
Reveal app details
Install app
View installed apps
Configure settings
Edit app settings
Learn how to build app
I started by sketching the App Directory Landing Page, to try out different design patterns. I explored things like a prominent search (because users would want to quickly find specific apps they needed), and a "featured" section (helping users easily find the most popular apps).
The goal of the visual design was to match existing styles.
One of the many design decisions was: how many apps should we display on the main page? Hick’s Law states that the time it takes to make a decision increases with the number and complexity of choices available. Showing too many apps would be overwhelming, so I decided that 3 or 4 apps for each category was ideal: enough to get the gist of each category without becoming overwhelming.
I made a prototype in InVision to help with developer handoff, showing how pages should linked together. Watch the 40 second video to see it in action:
The "Installed Apps" tab makes it easy for admins to edit app settings. The "All Apps" tab helps a curious DevOps manager, looking for ways to improve their team's workflow, discover the most popular apps from each category. The categories we used were based on the card sorting exercises I did with users, with some influence from the Product Team, who wanted to promote things like Marketing and Security.
We removed the most eye-catching "featured" section to reduce development time and meet sprint deadlines.
.png)
Users also needed to be able to learn more about each app, install them, and configure settings:
I left PagerDuty before the App Directory was built, so I don't know how this design performed.
Learnings
An interesting part of design a platform is not knowing what the final content will be – for example, the app descriptions and screenshots for each app are written by the 3rd party developers who build these apps. This was a good learning experience in how to design components and page layouts that could support various content, giving 3rd party developers some flexibility, while also giving them boundaries to ensure the end user experience (browsing and installing apps) stays consistent.