Improving Native’s CMS: Duplicate feature case study
Project Overview
During this project delivery, Sakky B and I worked on improving Native’s CMS duplicate feature. After going through an extensive design thinking process, we conducted user feedback sessions, a kick-off call with the product team, and the 30 60 90 share back with all key product members to come up with solutions that would help improve our users’ overall experience when creating events on Native’s CMS.
- The problem: users found it time-consuming to constantly have to copy details from past events and paste them onto a form when creating a new event.
- The time frame: 1 week.
- The solution: improving Native’s CMS duplicate feature. This solution was agreed on by all product team members after identifying the main pain-point majority of users felt when using the CMS
Intro to Native
Native is a ticketing platform that helps students connect with amazing experiences whilst their time at university. They help promote Student Union virtual and IRL events across the UK.
To create and upload these events, organisers would have to use the Native CMS (content management system) which is an application used to manage their content & also allow multiple collaborators to create, edit & publish events.
User Research & Feedback
To better understand our customers and how they interact with the CMS, we reached out to a few users and booked 30-minute calls with each of them.
These helped us as we learnt about how they took us through how they currently use the CMS & we understood issues they faced on the usability and functionalities of certain parts of their journey.
It helped us determine the basic ‘pain-points’ of CMS users when it came to creating events. The majority of pain-points were directed towards constantly having to copy existing events to retain similar details that would be used again when creating a new event.
One of the questions we asked a customer:
What else are you using the CMS for?
“Being able to repeat an event. You can currently copy the event, but would be better to have something where we have an option to automatically fill out existing details like the events location.”
The Problem
Users find it time consuming when creating an event that has the same details as previous events. Most users currently copy all details from past events to save time when creating a new one.
⚽️ Kick-off call
We always start of a new project with a kick-off call. This meeting is to get all the key players together in one room to share information and align to a common purpose.
It’s an opportunity to set expectations and set guidelines to complete the project on time.
-Identify the project’s goals and deliverables.
-Identify team members and their responsibilities.
-Develop a rough product plan.
-Define the key success factors.
After the kick-off call we agreed on two areas to explore to solve the problem
Option1: Implementing an option to create a template for an event.
Option2: Adding an option to duplicate an existing event.
3️⃣0️⃣% — Product Research
To understand which option would be better to go ahead with we looked at both competing products and popular platforms that had the template feature.
Competing products:
-Fatsoma
-Eventgenius
-Eventbrite
Popular products:
-Notion
-Asana
-Coda
-Trello
HMW
How might we reduce the time taken for organisers to create new events/ recurring events?
Our product research involved intensive critiquing on the UX & UI of each product. Identifying similar design patterns throughout these products helps us understand whats best to implement onto our designs for Native’s CMS.
Our Goal/ Solution
After looking at what other ticketing platforms did with the duplicate feature, we decided to go ahead with the duplicate option as the ellipses already had the option to duplicate but only the event details would duplicate & other information like the ticket details and additional info on the event would not. This was mainly because of the development complexities. Creating a template would require more time and this project was to be delivered in a weeks time.
6️⃣0️⃣% — Lo-fi & Journey Maps
After the 30% share back with the Product Manager, our next steps were focused on mapping out user journeys for the duplicate flow. We presented different options a user could take when duplicating their events.
EventGenius inspired one of our solutions, a modal for duplication. In the modal, the user would have to add in a new name for the event, set the dates, and also choose if they’d like to duplicate the tickets and additional information along with the event details.
We realised that if we want to duplicate all tickets from a previous event, the sales dates added a new level of complexity, and therefore we came up with 4 different options for how to tackle them, each with different pros & cons.
When going through the user flows, it was important to have the whole team present to discuss on any complexities that may arise with our proposed flow and options presented.
We presented the options and everyone agreed that the reccomended solution was the best to proceed to high-fidelity.
9️⃣0️⃣% — Hi-fi Designs
After agreeing on the proposed user-flow, our next steps were to create the modal design and changes on the existing designs for dev sign-off. The CMS already had existing modals therefore it was important to try and reuse available components to create a similar design pattern instead of introducing something completely different.
Helpful tip- When working with devs, create a figma file with decks for each of the changes being made on the product & then add sticky notes specifying the exact changes being made on each page/ step.
Conclusion
Reducing users’ time for creating new events on the CMS with the duplicate feature was challenging due to time constraints but also rewarding at the same time. Having done product research on competing products was really helpful as we leveraged most of the design patterns and journeys into Native’s CMS.
As simple as a duplicate feature may seem, it turned out to have several complications in terms of considering ticket date sales having to automatically change when duplicating a past event.
The 30 60 90 share backs have always helped us get our project in the right direction and get constant feedback before taking the next steps.
What went well:
- The design process we used was really helpful for delivering the project.
- Call with development team helped designers understand the complexities of some options we planned on implementing.
- All product team members were well informed on the changes/ decisions being made throughout the design process.
- Project delivered on time :)
What didn’t go so well:
- Even though we were able to deliver this project on time, we all agreed on prioritising future project timelines to not rush through them.
- During the 30% share back on product research, only the PM was present. We realised it was important to have the development team in that call as well, as it causes less confusion when presenting our proposed user flows.
