Sending Hours

⏰

Sending Hours ⏰

 

Challenge

Modica is a global CPaaS platform supporting communication with any mobile on the planet. They do this via a suite of API’s (HTTPS, REST, etc) and applications (OMNI Web2SMS, etc).

Modica accepted a statement of work (SOW) from a large customer with a powerful need: never disturb customers outside of business hours.

Response

7 people from across Modica’s Product, Sales, Service-Delivery and Tech teams worked together to deliver this SOW.

The initial SOW included quite prescriptive requirements (e.g. “include a big red button to stop all messages from sending.”)

By stepping all stakeholders through the Design Thinking process, we were able to solve the core problem that had given rise to the original, prescriptive SOW (without strictly adhering to every requested button & field). The customers were happy with both the product and their experience with us.

 
 

Requirements analysis

- Considered our account/sub-account structure.

- Mapped how this would impact data record’s:

◇ ownership

◇ visibility

◇ unique values

 

USER FLOWS & DESIGNS

- Determined functional states (e.g. open & sending, or closed & queueing) and set the default/null behaviour.

- Considered combinations of interactions (e.g. no Sending Hours set, then a Restricted Date is set…)

- Accounted for extremes (e.g. sending/deleting 1,000,000 messages).

 

RESEARCH PROTOTCOL ◆ PROTOTYPING ◆ INTERNAL TRIAL RUN - INSIGHTS

 

USER Testing - Round 1

Findings

  • Confusing terminology, which set inaccurate expectations. ◆ “Default window… I don’t understand at all what this is” - User 2

  • Frustrating window:account relationship. ◆ “But… I can see all of the [4 accounts] when I’m editing this window?” - User 2

  • Low findability of core functionality. ◆ “Can I [create a default window] from Scheduled [tab] as well, for this particular day?” - User 1

SUS Score

  • 57.5 - D grade - marginal

Recommendations

  • Match customer mental modal for terminology and the account:window relationship.

  • Uncouple the two actions ‘create’ and ‘assign to accounts’.

  • Increase find-ability and differentiate the types of ‘windows’ by removing options from a dropdown and separating into distinct CTA.

  • Simplify the JTBD of the Active Windows tab.

 

user testing - round 2

Findings

  • We should set the Overview as the landing page, and increase the data displayed, to enable users to confirm their previous actions.

  • Error rate decreased, and SUS Score improved to 86.

 

tested in round 1

tested in round 2

 

Key takeaways

Start with the ‘Why’

  • Keep coming back to it - in this case it was "never disturb customers outside of hours.”

Account Managers are Fabulous

  • Account Managers already have existing positive relationships with participants/customers!

  • Ours were great at observing during the testing, but jumping in to answer account-specific questions.

Learnings

  • Consider what information to display at every step, to best assist users in achieving a goal. Then apply Occam’s Razor.

  • If records or instances of something are time-bound; design for expired and archived behaviour.

  • Ask early about back-end functionality, including the speed to add or delete records, regularity of cron-jobs, etc.

 
“Since we had such great success using this UX-led process, will we be doing more of this in the future?”
— Account Manager, Q1 Update Q&A 2023
 

tools

JIRA - Figma - Slack - Zoom - Google Presentations - Postman API - Google Spreadsheets - Confluence