Problem
Data have shown that a significant number of updates were failing because users submitted the same request multiple times in a short span of time. A high number of failures were also due to users submitting the same request after it had already failed before.

Objectives and limitations
Decrease the percentage of failed updates without making structural changes.
Make the information more clear without overwhelming the user.

Assumptions
It's not clear if a requested update is being processed and how long it might take.  Prioritising this information and letting the user know of the issues created by submitting the same request multiple times will decrease the percentage of failed updates.

PART 1 - CONFIRMATION MESSAGE

I have shortened and made more clear the information while highlighting the time needed for an update to be processed. I have rewritten the CTAs making them more specific so that it is clear for the user what they need to confirm.

A message informs the user when an update has failed and instructs them to check the service log and to contact customer support to solve the issue.

Results
In less than two months after our design has been implemented, the percentage of unsuccessful updates almost halved.

Observations for further improvement
The CTAs of the two services are inconsistent.
The title "Manage service numbers" doesn't explain what the user can do in that section.
The information about the amount of phones that have been selected might be confusing as that sentence must also explain to the user what action they need to take.
The user experience should be simplified for both "Manage service numbers" and "Update services"

Problem
Qualitative research has backed the problems we noticed during the previous project. Furthermore the features that the user can manage are limited and disorganised.

Objectives and limitations
Improve the user experience for service management.
Add more features despite limited space.
Create a design that could afford to include more services to manage in the future.

PART 1 - SERVICE SELECTION

I have renamed the services to make it clear what they are for. The design based on card elements will allow to add more services in the future. This way the area where the user selects and manage the services and the area where they select the phones will always be at the same height regardless to the number of services that will be added.

PART 2 - NETWORK FEATURES

I have renamed the network features to make them immediately clear and I have grouped them based on the type of service they relate to. This allowed to keep the list compact despite we had added 18 new features. Furthermore, it allowed to solve another problem arising from the previous design. In fact, the "bar" features had the opposite behaviour than the others. and when toggled on they blocked the corresponding feature. Clustering all the "bar" features in one group made their functioning easier to understand.

However, some of the "bar" features belonged to other categories. For example, amongst the new features we added, there was one called "Full roaming bar". Including this in the "restrictions" category when it clearly refers to roaming would have been wrong. For this reason, I have looked for all the similar cases and I have suggested to revert their logic. So, "Full roaming bar" became "Roaming capability" allowing roaming when on, and preventing it when off.
I have also rewritten the names and descriptions of most of the features to make them more clear. Finally, where possible, I've suggested to merge the features that could be handled together. The resulting document, which included names, descriptions, and functioning of each feature, has been discussed with the P.O. and several other stakeholders, and has eventually brought us to reach the definitive list of features to be included on the platform.

A message indicates the number of selected updates for each group. This way, the user has always an overview of their choices. Furthermore, through the dedicated icon, the user can visualise a description of each feature.

The new iteration of the confirmation request message indicates more accurately the time needed to process an update.

PART 3 - PAC/STAC & DISCONNECTIONS

In the same area dedicated to the request for PAC, STAC, and INFO codes we have also added the possibility to ask for the termination of the contract, which previously had to be managed in a different area of the platform.

The new iteration of the confirmation message for the PAC, STAC, and INFO codes improves information's clarity and readability.

I have also writte a new confirmation message for disconnections.