MTRIBES: Recurring Schedule

MTRIBES allows non-developers identify how users are engaging with UX in real-time, group customers into dynamic tribes based on behaviour, interest and demographic, create and publish personalised campaigns, and measure the results all without a line of code.

the user can schedule to show, hide or display variants of their components within their apps using time, date and time zone parameters.

The Problem

MTRIBES only allowed it’s users to have a single schedule per experience.
This complicates things for users when attempting to publish content with complex recurring schedules, forcing them to have to duplicate the content to create more granular schedules.

Why

Productboard Feedback
Utilising Productboard, our clients were able to vote and comment on roadmap features. Allowing us to gauge the priority. The feedback also included a lot of valuable use cases that served as a foundation of our requirements.
Existing functionality
During the initial build of MTRIBES, the scheduling functionality was created as an MVP solution, Only allowing single schedules. Resulting in clients duplicating of experiences in order to achieve flexibility. Complicating the workflow workflow for publishers using MTRIBES.

Goals

Efficiency

Enable users to schedule content publication in advance, reducing the need for manual intervention.

1

Flexibility

Offer flexible scheduling options to accommodate diverse publishing needs.

2

Reliability

Ensure the system is robust and dependable, accurately publishing content according to the specified schedule.

3

User Satisfaction

Enhance user satisfaction by simplifying the content management process and empowering users with greater control.

4

The Process

We utilized a process based on the double diamond framework, adapted to fit our product teams pipeline. Involving relevant parties throughout each phase in our projects and features.

Understanding the problem

We gathered user feedback using Productboard. Allowing our clients to either vote on roadmap features or suggest ones based on their use cases and pain points. There was a high frequency of requests to expand our scheduling functionality by adding the ability to create recurring schedules.

We based our use-cases on client comments from Productboard. This allowed us to focus on creating a feature that solved a lot of customer pain points than simply adding recurring schedule mechanism without grasping the bigger picture.

Users

Key Audience of this feature would be content Publishers using MTRIBES.

Use Cases:

Our most active time for subscription sign-up is 30 mins before each live sports game starts, through to 45 mins into the game.

I want to:

display a short form content on the homepage at these times.

Our short form content is most likely to be consumed between:
07:30 - 09:00 and 17:00 - 19:00,
Monday till Friday.

I want to:

display a short form content on the homepage at these times.

We have a sporting event that starts at 22:00 and finishes at 02:00 next morning. Then again between 08:00 and 12:00 every Saturday.

I want to:

Display a banner on the homepage promoting whenever it is live.

market research

Research of various competitors and products using recurring schedule implementation was useful to reference different mechanisms. However, Each competitor’s or software’s recurring schedule functionality was built around a specific context. None of which provided examples of solving similar use-cases to ours.

ideation and exploration

The design team got together early to workshop the direction of the feature, breaking down use-cases from our clients feedback, to creating some high level sketches on the whiteboard.

One of our early options referenced our in-house presentation manager used on our product AXIS. Presentation manager serves as the web interface used to manage content on AXIS. It also features a recurring schedule mechanism our customers were familiar with, so it served as a good baseline of what our customers would expect.

wireframing

After generating ideas and deciding on a few options to explore, I begin to create wireframes based on everything gathered and explored so far.

Below is an example my of wireframes covering key screens and states, accompanied by annotations outlining rules and behaviour.

Multiple Recurrences

Exploring nuances of having multiple recurrences as well as thinking through implications of removing them for an active experience.

Recurrence options

Working through various mechanisms that satisfies our user needs. While utilising clear language and UI elements to ensure a reliable user experience.

Edge cases

Exploring and documenting validation and errors the user may encounter.

challenges

Separating scheduling section
Currently living inside of the targeting section tab, the addition of extra components within the scheduling section would extend the panel’s height. We considered moving the scheduling mechanism to it’s own tab.
Choosing mechanism and language
Our scheduling mechanism needed to account for a few use cases where a schedule runs over midnight. In order to create a simple to use and clear UI the scheduler could trust, we needed to ensure we picked the right mechanism and language to accompany it.
Supporting Multiple Recurrences
One of our key requirements is allowing the operator to have multiple recurrences. Allowing cases such as showing content every Wednesday, as well as on the weekends.

To ensure the operator doesn’t resort to duplicating their content to create another recurrence, we’ll need to create a unique mechanism that allows multiple recurrences while being easy to use.
Distinction Between a Regular vS Recurring Schedule
In order to reduce the number of one-off components across the app, we utilise existing components as much as possible. This introduces a slight complexity as the fields used for a single schedule, become the schedule time-frame when recurring schedule is enabled.

cross discipline collaboration

I'm a big believe in making sure not to work siloed from the ret of the team. Here is a brief summary of collaborations that have taken place during this feature, and across most others I've worked on.

  • Design team check ins for transparency and retaining momentum.
  • Feasibility catch ups with developers to ensure we don’t detail solutions that won’t be possible with our current resources, tech or knowledge.
  • Sharing early explorations with developers and quality assurance teams to gather technical insights that help shape the solution.
  • Stakeholder check-ins to present progress, and discuss decisions that are backed with research and usability testing results, as well as addressing any feasibility concerns.
  • Kick-offs with relevant teams when designs are ready for development.
  • Working with copy writing teams to assist with release notes and help centre documentation.
  • Grabbing a good bite at the pub to decompress.

design process documentation

Design process documents, internally referred to as DPD’s, serve as a point of reference of the decisions made to complete a feature.

Future teams can use it to gather insights into decisions made, leaving ambiguity of why certain things were built the way they are. Giving further insights into any technical challenges, constraints, research and usability testing results that shaped the decisions and solutions.

  • Separate to our UX documentation and any visual design specs provided to developers.
  • Includes goals, use-cases, competitor research, testing results, decisions and retrospectives, future considerations.
  • Learnings section also allows the designer or designers working on the feature to look back on and reflect what could be done differently in the future for a more efficient process.

Facilitating usability testing

Since there's only so much data to be gathered from competitor research. To back more complex decisions, usability is a great way to get insights into how functional our intended solution really is. However, despite the importance, not every project and feature will allow resources for testing.

Usability testing is a large topic, this section is a brief summary of my approach. I often reference Nielsen Norman group articles and studies to gain further insights for best practices.


https://www.nngroup.com/articles/usability-testing-101/
https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

Resourcing

Usability testing can be a resource heavy task, we took the opportunity to combine the testing with 2 other ongoing features.Since all of the work took places on the same page as scheduling, it made sense for us to write the testing protocol so it lets us validate 2 other features in one go.

Testing Protocol

Unfortunately I no longer have access to the final script we ran our testers through, however here’s a baseline we drafted prior:

Insights

After synthesising the results using affinity mapping we gathered the following results:

  • 2 out of 5 Users didn’t initially understand the requirement to set a timeframe for the recurring schedule.
  • 1 out of 5 Users didn’t find the terminology “same day” “next day” immediately clear.
  • All users completed setting a recurring schedule in the end.

Digesting Resuls

Despite most of our participants successfully completing the recurring schedule, we saw room for improvement in the following areas:

  • Improved copy to accompany each part of recurring schedule, proving context to the user.
  • Improved hierarchy to reduce user error.

Iterating based on testing results

To address some of the concerns spotted in testing and reduce user error. We went ahead with re-arrangement of the section. Improving hierarchy by placing the recurrence fields first followed by setting of the timeframe the schedule will run for.

This change brings the recurrence fields to focus first, where previously the user may have filled out the timeframe first and potentially ignored the recurrence fields resulting in an error.

This would also create a visual distinction between the one-off and recurring schedule.

Outcomes

The addition of recurring schedule allowed clients to maintain a cleaner UI by reducing the need to duplicate experiences for each schedule, in turn simplify their workflow.

Revised layout after testing:

  • Improved hierarchy
  • Additional copy providing further context of each section.
  • Revised visual design on field components to reduce excess height.

New scheduling in-situ:

Layout before usability testing:

Scheduling before this project:

Case studies:

AXIS: Hero Carousel

Creating a hero carousel component for a multi-platform service.

AXIS: Design System

Creating and maintaining a design system for an existing white label product.

Let's get in contact

While this website summarises my experience, it only scratches the surface. Let's connect so I can dive deeper and explain how I benefit your development process, team, and company.
E-mail
Linkedin
CV