Designing a release note campaign manager — UI/UX Case study.
In a hurry? Here’s a short video of me showcasing my process at the Whiteboard FM podcast.
Olvy is a release note hosting service for products. Its features include release note’s integrations, customer feedback analysis options, and online community building functions.
The challenge was to create a feature that allows users to subscribe to release notes and receive updates via email.
Design, discovery, and deliverables
As the sole designer on this effort, I gathered all the technical requirements and constraints, worked closely with the founders of the product to design the campaign manager on Olvy to conceptualize the problem, define significant pain points, and produce tangible concept prototypes to test with the users.
By leveraging the existing research and usability feedback, I was able to empathize with customer needs and usability behavior.
👵 Takeaway 1
Personalized and curated emails resulted in much higher open rates from users than more general-purpose email campaigns.
🕰 Takeaway 2
Importing contacts can only be done manually and on a case-by-case basis. Customers worry about non-tagged connection ending up in a long-pending queue for moderation and tagging.
🤝 Takeaway 3
The current UI in the existing competitive systems does not allow for release note’s specific, context-aware rules, which impedes trust in auto email campaigning.
After syncing with internal stakeholders, I iterated on low fidelity concepts for advanced release note campaign creation and subscription.
To create a scalable campaign management system that increases the efficiency of creating and editing release notes emails. This system must handle multiple states of the application, such as staging and production. The customers publishing the release notes can work in parallel with the developers managing the product. As Olvy continues to grow and adds new features, this system must also scale with the team without compromising its architecture and usability.
Allow for more complex rules by assigning actions to multiple categories and conditions.
This meant expanding the drop-down selections and thinking of ways to present options without restraining the user. I also had to balance this with providing users with the right set up opportunities based on data analysis because it would be inefficient to develop options that won’t get used.
Maintain the consistency of the current design system.
Since Olvy already had a design system, the current use cases would naturally need to fit the existing structure; additionally, it was easier for the backend to implement this format.
Not all publishers were familiar with the advanced interface.
The interface should be as flexible as possible without taking away from basic rule creation. Even though the project scope was narrowed down to more technical use cases, it should be usable on a spectrum of abilities.
In order to test how effective our concepts were, I created a high-fidelity prototype.
- People use your product to complete tasks — every new feature will always be part of a repetitive workflow — both in the software and outside.
- Less is more — users interact with the flow several times, the interface needs to be, most importantly — functional Users would love to help you since it affects their workflows.
- Establish a good relationship early on — get constant feedback from the user, empower them.
In the future, I will show work earlier and more often and seek more mentorship from the core-product team. If I were to do this project again, I would conduct more preliminary research with our target customers to better validate my design decisions.
This was a solo capstone project given by team Olvy during my time at 10kdesigners. I got to help facilitate, lead a research meeting to share my findings, sync with co-founders, and chat with my design mentors outside of work. I’m excited to see what products the team develops next!