for virtual network
01 _ THE PROBLEM
Openet’s Offer Catalog provided virtual network operators (VNOs) with the capability to create, deploy and manage digital offers, across a mobile network.
Offer Catalog had some usability issues when it came to configuring offers requiring time based conditions. Customers complained about this and requested a solution. They needed a way to schedule the availability of their offers across a network.
02 _ OBJECTIVES
Improve the user’s experience
I had three primary design objectives.
1. Improve the user’s experience.
2. Design for business & customer needs.
3. Maintain company style & brand.
03 _ PROCESS
A user-centered design approach
My design process began with trying to understand who my target users were. To do this, I contacted Jurgen Schuttke – a Solution Architect at Openet and a technical expert for Offer Catalog. He helped me understand who I was designing for and provided key insights into usability issues that customers faced.
Simultaneously, I researched Openet’s Offer Catalog. I needed to understand how it worked because the application I was about to design, would work adjunct to Offer Catalog.
04 _ METHODOLOGY
Inspired by Design Thinking
Throughout the duration of this project, I was studying Design Thinking through the Interaction Design Foundation. I wanted learn more about design methodologies, creative thinking and problem solving, ultimately to become a better designer. Inspired by this, I started to apply what I had learned to my work each day.
05 _ JOB STORY
Eager to learn more about the Jobs-to-be-done framework, I conducted my own research on the topic. I learned that the Jobs-to-be-done “lets you focus on making things people actually want. It’s easier to make things people want than it is to make people want things.” – Traynor, D., 2016. Intercom on Jobs-to-be-done.
I used the Jobs-to-be-done framework as a starting point to help steer the design process. I created some job stories with one example being the following:
06 _ FLOW DESIGN
Understanding the user’s flow
To provide an understanding of my design, I created various user flows. The flows helped the project team collectively understand my design approach. The Times Module functioned as a support module to its parent application, Offer Catalog. A user would create a network offer using Offer Catalog, then configure timing conditions using the Times Module.
07 _ MODES
Configuring time schedules using three modes
Mode 1. Only weekly reoccurring times.
Mode 2. Only special case times.
Mode 3. Weekly reoccurring times + special case times.
The request for special case times came from one of Openet’s customers. Sprint, one of the largest mobile network operators in the United States, requested the ability to configure special case times* when offers could be made available across their network, particularly during sports games.
*Special case times were one-time events. For example, a network operator could apply free data across their network on public holidays, during national sports games or one-time special events. Special case times also took precedence over times that were configured on the weekly schedule.
Only weekly reoccurring times
The availability of mobile network offers could be scheduled to reoccur at specific times each week. An example might be ‘peak’ and ‘off-peak’ times for mobile data offers.
Having a fast and efficient way to set timing conditions would decrease configuration times and ultimately provide a better user experience.
Only special case times
Special case times* were specific periods of time during a year that did not reoccur each week. For example, a network operator could create a schedule that provided ‘free data’ to all its customers on each public holiday throughout the year.
Similarly, a network operator could configure the availability of “one-time offers” during sports games, on specific dates and times in the sporting calendar.
Weekly reoccurring times + special cases
A combination of mode 1 + mode 2 could be used. An important factor when using this mode of configuration is that special case times had a higher precedence over anything configured in the weekly schedule.
08 _ INTERFACE DESIGN
Designing the interface layout
The Times Module had two primary interfaces, the weekly schedule and the special case configuration screen. In order to optimize the user’s experience, I wanted to minimize the quantity of screens and the amount of functionality on each screen.
Interface 1 – Weekly schedule
Interface 2 – Special case configuration
09 _ DESIGN SYSTEM
The application’s design was based on the principles and styles of Google’s, Material Design. All of the components, layouts, and typography combinations were made according to Material Design specifications.
An open source library was used for the development of the weekly schedule component.
10 _ COMPONENTS
Designing interface components
Although Google’s Material Design system was extensive, I still needed to design some bespoke interface components. A time segment, colour picker and time band dialog were some examples.
11 _ THE SOLUTION
The primary objective was to focus and simplify the user’s experience.
While working on this project, I was juggling a lot of things. I needed to design an application that primarily, met customer needs through UX improvements. I also needed to design an application that worked with an existing system (Offer Catalog), while adhering to Material Design specifications. The application needed to have a fresh new look, be intuitive and work well.
Time schedules directory
A time schedule was a group of timing rules made from weekly time segments, special case times or a combination of both. A schedule could be assigned (as a condition for usage) to network offers in Offer Catalog. By doing this, the offer’s availability and cost to mobile customers across a network, was controlled.
Empty state design
When a new time schedule was created, an empty state was displayed with two parts. The first part contained generic details and a switch to invoke the use of a weekly reoccurring schedule. The second part contained a list of special case times that worked as “exceptions” to anything configured in the weekly schedule.
Weekly schedule activated (Empty state)
Activating the weekly schedule displayed the screen above. It enabled a user to configure and manage specific times a network offer would be made available to mobile customers. If the weekly schedule switch remained “on”, the timing configuration would run indefinitely. This provided a key advantage for network operators – they now had greater flexibility in controlling offers that required granular timing constraints.
Weekly schedule configured including special case times
As pictured above, a network operator could configure the times and rates to apply for the consumption of data across their network during each week of the year. They could also configure special cases when different (offer) availability rules and rates applied.
For example, if a mobile customer consumed data between the hours of 06:00am to 12:00pm, they were charged at a rate called ‘Morning time’. This rate was known as a time band. The ‘Morning time’ rate was charged at 0.5 cents/Mb, ‘Afternoon time’ rate was charged at 0.2 cents/Mb and so on. Depending on the time of day a customer was consuming an offer (data), they were charged differently.
Special case times had a higher precedence over configuration contained in the weekly schedule. The availability (times) of a network offer and associated rates (time bands), were configured on the weekly schedule. If Christmas Day (Special case no. 3) occurred on a Tuesday, all configuration rules contained on the weekly schedule for Tuesday, would be ignored. A different rate of ‘Weekend_Holiday’ would be applied for consuming data on that day. A ‘Weekend_Holiday’ rate might cost 0.0 cents/Mb, as a gift from the network operator during special times of the year.
Configuring a special case time
A network operator could configure specific days throughout the year when a free offer applied. For example, mobile customers on a ‘Bill pay’ plan could receive free data and free calls on bank holidays throughout the year. ‘Bill pay’ customers would be charged for their mobile services each month as normal, yet on bank holidays, they would receive services for free. This allowed network operators to configure special cases (in this example, bank holidays) once, and allow the configuration to function indefinitely.
13 _ QUALITY CONTROL
I worked closely with the development team to ensure each interface was developed as outlined in my specification. I managed this process using ‘Red line’ documentation and comments in Zeplin. This process ensured that my designs were implemented perfectly.
14 _ DESIGN DECISIONS
Design details are very important to me. They reflect who I am as a designer and add value to my designs.
I care about my work and having a strong attention to detail. This is why I paid close attention to every detail I designed. Below are some subtle design details which proved to be important or difficult to design.
I carefully selected and tested each colour for the colour picker component. The colours needed to adhere to Material Design specifications while providing enough contrast. I found that lighter shades, such as yellow, did not provide enough contrast against the white text of each time segment. Due to this, shades of yellow and similar colours, were purposely omitted from the palette. The chosen colours were tested for contrast and variations of colour blindness using a Sketch plugin called Stark.
Error avoidance and reducing cognitive load
Early in the design process, I discovered that inputting time values manually was a cumbersome and error prone action. It caused frustration and I felt the user’s experience needed to be improved.
Although I designed error messages to help guide the user on the correct time format to use (HH.MM), there was a better solution. I designed a single-click menu with fixed values (00-23 for hours and 00-45 for minute increments). This subtle design detail improved the user’s experience because error messages would no longer appear and the user had less to think about, i.e. what they previously needed to type.
Designing for short time periods
When a new time segment was added to the weekly schedule, its default duration was for two hours. I purposely designed it this way because visually, a two hour time segment was large enough to display the default textual information. I did not want the text size to enlarge or decrease in size depending on the duration of each time segment. I wanted the text to remain a consistent size. For shorter time segments I designed tool tips that provided the same textual information.
When the Times Module initialized for the first time, a user was operating it in an empty state. The application had no configuration data available. To help the user, I designed tips as a method to provide guidance. These tips were designed to be displayed for a short period. When enough data had been configured, these tips would no longer be displayed because at this stage, the user would be familiar with how the application worked.
Telecoms terminology and concepts were often difficult to understand and design for. Designing verbiage for the Times Module proved to be an awkward exercise. Attempting to describe the function of the ‘Default time band’ was difficult. Describing a ‘Special case’ also proved troublesome. The verbiage needed to be as simple as possible, in plain English without sounding overly technical. I spent hours debating different versions of these sentences. At times it was frustrating and humorous, but in the end, the above examples are what I settled for.
15 _ CONCLUSION
Before the Times Module was implemented, users of Offer Catalog needed to create network offers individually in order to set specific timing constraints. This was laborious task which resulted in poor usability. With the implementation of my design, this was no longer the case. Usability had been improved and network operators now had the flexibility to design bespoke scheduling for their digital offerings. The design objectives had been met.
Working on this project improved my skills as a designer. At times, I had a tendency to over-design. This was because I wanted to impress. I sometimes designed too many features in order to make a design look cool and interesting. My colleague Graham Sysko was really good making me realise this. From then on, I began removing all unnecessary features from my designs. I questioned the reason for, and the value of each element I was designing. Why? To improve usability. If a user has less to think about, it’s easier and more enjoyable for them to use your design / product.
Overall, I was happy with the design and outcome. The development team did an excellent job, particularly towards the end of the project, when applying the final touches and CSS updates. I strived for pixel perfection, the development team delivered on this and I was happy.