Hey!
I'm Himani Singh
Experience Designer & Illustrator.
US Telecom Project
Feb 2024 - Mar 2025
Simplifying Device Management
The case study presents a data-driven redesign for a Leading US Telecom Client. It covers three core device management flows: Change Device, Change SIM, and Activate Device built for SMB users.
The business platform of the client helps admins and customers manage multiple devices and wireless lines. Here, small and medium business users can do everything from suspending lines and activating services to updating user info or purchasing SIMs and plans.
My Role
We were a team of three UX designers where I also served as the sole UI designer, taking complete ownership of the interface design for responsive as well as web-view designs.
I was responsible for designing all screens, creating detailed prototypes, and defining the interaction of each element. With the strong grasp of Client's design system, I ensured that the visual design stayed aligned with the brand and also served as the primary UI auditor during the development phase.
What did we discover?
But one flow in particular, the device management flow was causing a lot of frustration. It turned out to be one of the 3 flows with the lowest CSAT score and task completion rate of 2.7%.
The Device management flow consists 3 key tasks:
1. Activate Device
2. Change Device
3. SIM Change or Refresh (Term used when moving from an eSIM to another eSIM).
1
Activate Device
Moving a wireless number/line to a newly upgraded device as well as activating the device.
2
Change SIM
Switch to a different SIM type or request a replacement (due to loss or damage) in the same device.
3
Change Device
Move a wireless number/line to a different device. This could involve a change in SIM types as well.
Basics of devices
IMEI ID
Each device has an 15 digit Device ID / IMEI ID.
Single compatible device have a line active in 'IMEI 1'
Dual compatible devices can have 2 lines active at the same time in 'IMEI 1' & 'IMEI 2' respectively.
SIM Types
There are 2 SIM types eSIM(Embedded SIM) and pSIM(Physical SIM). All SIMs have a 20 digit SIM ID.
A line in a pSIM is active in 'IMEI 1' of the device and in case of an eSIM, it can be active on 'IMEI 2'
How does it work?
All the 3 tasks are performed in one master screen. In this flow, user can only select their intended task out of all tasks once the Device ID has been entered and validated.
Select line
Current Master screen: One fits all approach
IMEI validation
SIM Change
Current Device details
SIM ID for pSIM
Device & SIM ID help
Insights from UX research
To figure out why users were unhappy and struggling to complete tasks, we pulled out insights from heuristic evaluation, VoC (Voice of Customer) analysis, and data metrics. This helped surface edge cases, primary use cases, scenarios, and valuable inputs from competitive research.
Clarity & Cognitive Load
-
Users were overwhelmed by multiple undifferentiated tasks in a single screen and unclear information architecture.
-
No clear guidance on next steps or sequence of requirements
-
Heuristics revealed poor visual hierarchy and weak UX writing.
Usability & Interaction Friction
-
Users manually enter long identifiers (IMEI/SIM ID) and often twice.
-
Accordions mimicked dropdowns, causing misinterpretation.
-
Inconsistent tertiary CTAs, popups and other UI elements created unpredictable user journeys.
Error Handling & Support Gaps
-
No clear messaging after failed transactions or errors
-
No support post-failure
-
Lack of error prevention
-
Inconsistency and absence of confirmation popups
Performance & User Behavior Data
-
Low task success rate flagged a high drop-off
-
Funnel data highlighted primary problem areas/steps of the flow through fallouts metrics.
-
Current approach fails specifically for singleline than bulk and multiline use cases.
-
Each device type has its own ID format and needs specific self-help based on the digital mix data.
Need for redesign
-
One size fits all approach fails to provide an intuitive and clear path to completion
-
We donot accomodate dual-compatible devices. Previous designs didn’t account for dual compatibility. It was only imei Compatibility. If imei entered is compatible with pSIM, activate a pSIM or buy new pSIM and if it’s compatible with eSIM activate an eSIM
-
There is a lack of clarity regarding actions required after the transaction is completed.
-
Performance related issues limit the optimization of usability, such as filtering data based on activation status.
-
API issues, such as the inability to inform users about activation failures or fallouts upfront need to be addressed
Key features
We explored several concepts based on stakeholders discussions and business requirements. There were changes in direction, differing opinions, and quite a few back-and-forths during cross-functional collaborations. These helped us learn what worked and what didn’t, and finally led us to a solution with the following strong KPIs:
1
One Click Activation
Simple and direct flow for activating pending upgrades. We can pre-populate new device details in case of activation. Hence, one step activation is possible. User doesn't need to enter 15 digit IMEI of the new device as servers save information of the upgraded device for upto 90 days. Information can be fetched as soon as the line is selected to activate.
2
Dual Compatibility
Dual-compatible devices don't require entering the IMEI twice. One device has 2 IMEI IDs. Device's One IMEI ID can fetch compatibility information of the device as well as the other IMEI ID.
3
Post Transaction Clarity
Immediate status visibility and quick help after completing the flow through test call and troubleshooting features. Multiple ways to provide additional support like chat, call scheduler, call and tickets can help deflect calls to the support center.
4
Guided Experience
Educational aspect for 3 tasks, SIM IDs as well as Device IDs can help users understand and follow steps. Direct and smartly positioned copy which doesn’t distract user and yet educates them.
Conceptualisation
We mapped out 12 potential use cases by combining different SIM and device change scenarios, narrowed them down to 4 primary ones that covered the most common user needs. This helped in prioritizing scenarios and shaping the overall concept.
a.
Conversational UI
A progressive approach helps users feel in control and move at their own pace.
Empathetic and conversational copy shows we understand their goals and are here to help.
b.
Multi-Action
Enhance existing experience and keep all task flows streamlined.
One of the concepts proposed efficient designs for multiple tasks in a multiline scenario. Working on the heuristics alongwith major UI enhancements.
c.
Authentication
Authentication/auto detection of Device ID can help reduce the struggle of finding first and second device ID.
This will also reduce human errors while manually entering 18 digit IMEI ID.
Final Concept: Primary Approach: 2+1
We planned to segregate the tasks into 3 which would allow users to address each information separately.
We originally planned to split the master flow into three separate ones, but had to rethink that due to technical limitations and multiple practical reasons that made it difficult to separate Activate Device from Change Device.
We cannot segregate the change device and activate device flows.
We finalised 2+1 approach merging Device Activation and Change Device, and separating change sim as another flow.
Why did we choose to merge 2/3 flows instead of segregating all 3 flows
-
At the entry point, wireless numbers listing can’t be filtered by activation status because of a technical constraint.
-
Two(Change device, activate device) of 3(Change device, change sim, activate device) tasks have the highest transaction numbers.
-
Change device and activate device are usually a cause of confusion because in both a line is shifted from one device to another whereas in change sim the device remains the same and only the sim changes.
-
Activation pending status of a line becomes change device eligible after 90 days. Activate device details are saved upto only 90 days. After that user needs to inout details of the new device manually.
Redesigned Flow
In this approach, when user selects a line and moves ahead without knowing the activation status, they would be automatically be redirected to the appropriate flow(Change device or Activate device) based on line eligibility.
Change/Activate Device
.png)
Change/Refresh SIM
.png)
Wireframes
Activate Device
Change Device
Step 1: IMEI validation
Switch to the other flow for initial months for easy adoption of the new flow for users.
Contextual Help
Step 2: SIM selection
Step 3: Validation for clarity on next steps
Alert for Plan change required in the next step
Other complex combinations of IMEIs & SIM types require additional alerts
Change/Refresh SIM
Post Transaction Experience
This screen provides clarity on what happened after the transaction — whether successful or failed. It also guides the user on next steps, support options, test calls and activation confirmation. Improved visibility of status, trust between system & user with #832 test call.
Troubleshooting instructions
Test call nudge
Changes based on feedback from VOC collected in 1 month - Merge troubleshooting steps with test call details.
User Testing
To validate the new experience before moving ahead with the final UI and concept, we conducted early user testing using basic prototypes and wireframes. This helped us catch usability gaps early on and shape the final design with confidence.
Collaborated closely with the user testing agency and provided briefing documents, refined prototypes and detailed questionnaires for interview moderators.
We tested key areas like IMEI assistance (positively received), self help, Refresh vs. Change SIM (some confusion around 'Refresh'), and Review & Submit (clear and reassuring for most users).
“Simple, super simple...I didn’t have to go to many places, there wasn’t an overwhelming choice of should I click here...I didn’t have to guess, it was straightforward.”
- Best comment from one of the users
Impact
Within the first week of launch of the Activate Device flow, there was a significant impact. Activation-based failures dropped from 11.32% to 0.3%. This proved the redesigned flow boosted clarity and task success.
Failure rate reduced by
11.32%
0.3%
Conclusion
The final deliverables included over 1,300 screens across desktop, mobile-responsive, and web views. We addressed secondary use cases and edge cases by designing for error scenarios informed by real user data and error frequency trends from the past quarter.
Along the way, we conducted multiple audits, demo sessions, stakeholder reviews, leadership presentations, and scoped the features/functionality for the next phase of the project.
Learnings
Stakeholder Management
Ask Questions
and validate the project scope with the right stakeholders.
Misalignments can lead to wasted design efforts, unnecessary iterations, communication gaps, and timeline delays. Receiving an official scope document and aligning on agreed timelines before beginning design work ensures clarity, accountability, and smoother project execution.
Early knowledge of
Technical Constraint
are crucial to avoid rework
Many technical limitations were shared after design conceptualization, resulting in design iterations and rework. Through this, we learned to proactively engage stakeholders early, identify their communication patterns, and ask strategic questions to uncover hidden requirements. This helped reduce ambiguity and unnecessary efforts.
Brand guidelines and Design system
Visual Heirarchy
must be designed
The limited flexibility of brand colors made it challenging to create strong visual hierarchy and scannability. I learned how to work creatively within brand constraints to establish clearer structure, using layout, spacing, and typography strategically.
beyond brand colors
Design systems may need
The existing Client's Design System, primarily tailored for consumer-facing experiences, lacked the flexibility needed for enterprise use cases. This required me to suggest multiple customizations and work closely with tech teams to bridge the gap—highlighting the importance of advocating for design scalability within existing systems.
Adaptation for complex business platforms
Product Learnings
Early User Testing
before final UI when a redesign introduces significant changes that require users to adapt to a
new experience. Early feedback on prototypes gave actionable insights which could be addressed before working on high-fidelity UI.
Design decisions need to
Align with tech feasibility.
Some ideal experiences couldn’t be implemented due to
API performance issues (e.g., real-time filtering of wireless numbers), so the design needed to manipulated according to what was feasible.
Error Prevention
is better than error handling - real-time validations, upfront eligibility info, and better UI
communication reduced dependency on support and cut down activation errors significantly.
Striking the right balance between
Informing users and not overwhelming
them with text heavy
screens (about device/SIM IDs, eligibility, etc.)
Introduce
Conditional elements that could help users adopt the new flow
Example, users are used to having 'change sim' feature in the same change/activate device transaction. Now to help users adapt to the 2 segregated flows, we decided to give users flexibility to switch to another flow. For first few months of launch, first few steps of 'change/activate device' have prominent call-to-action for switching to 'change sim'. Similarly a 'change device' cta is given in the 'change sim' flow.