UltraTone
A number is only
the beginning.
Buying a Cloud SIM was a digital transaction. Using it depended on physical hardware, available capacity, identity checks, and a limited activation window. I designed that journey while helping a telecommunications company establish its first design practice.
01 THE HARDWARE BEHIND THE INTERFACE
A switch could not create more capacity.
I joined a product that had already progressed without a dedicated design function. Telecommunications was a new domain for me. Before changing screens, I needed to understand how the service actually worked.
That meant sessions with the founder and developers, researching the devices behind the SIM service, and working through operational and pricing constraints. We wrote and reviewed Given / When / Then scenarios together to make the expected behaviour explicit.
The central challenge was an on-demand SIM that depended on a free hardware port. A person could own a number and have activation allowance remaining, yet still need to wait before using it.
02 TWO SERVICE MODELS
Choose how the number should work.
The purchase flow needed to distinguish two services with different availability and costs. I designed the Cloud SIM purchase and dedicated service flows directly, working with engineering to connect the interface to the underlying constraints.
Available without requesting an activation window.
A dedicated port kept the SIM active. The purchase design exposed the selected period and the setup cost in its price breakdown.
Activate when there is a reason to use it.
A shared SIM became active for a 15-minute session at the user’s request, subject to available capacity and activation allowance.
These are original design screens. Their prices and currencies are examples from the project, rather than a statement of current service pricing.
03 WAITING & USER CONTROL
Availability is an invitation, not permission.
An activation request could arrive while every shared hardware port was occupied. The interface needed to explain the delay, show an estimated wait, and let the person leave the queue.
We considered automatic activation when a port became free. The final decision was to ask the user to confirm. Someone who wanted to receive a message a few minutes ago might no longer be ready when capacity returned; starting the timer automatically could waste their session.
Check allowance and capacity.
Having activation allowance does not guarantee a hardware port is immediately available.
Explain the delay and allow cancellation.
The user can leave the waiting process without consuming an activation.
Let the user decide when to proceed.
Available capacity prompts a confirmation. Waiting does not start the active session.
Start the 15-minute session.
Allowance is deducted only after successful activation. The SIM becomes inactive again when the session ends.
04 TWO DIFFERENT LIMITS
A free port is not a free activation.
The designs used “slot” for two different things: a physical place in the hardware and an activation allowance belonging to the user. Those constraints needed to be understood separately.
Charge for successful use.
The monthly allowance was consumed when activation succeeded. Waiting and cancelling a pending request did not reduce it.
Additional activations could be purchased. In the design, purchased allowance remained available until used, unlike the monthly free allocation.
A user might need to buy allowance, wait for capacity, or both. Those are different next steps.
05 BEYOND THE HAPPY PATH
Purchase did not always mean ready to use.
The flow needed to account for changing number availability, unfinished checkout, pending identity review, and technical failures after activation.
Recover before continuing.
The purchase designs included replacing or removing a selected number that had become unavailable.
Release an unfinished selection.
The checkout had its own time limit. That reservation timer was separate from the 15-minute on-demand usage window.
Explain why activation is blocked.
The product used manual support review of submitted identity information, including self-recorded video in parts of the process. The dashboard connected a pending number to the KYC action needed to proceed.
Make interrupted time visible.
The source designs also covered a technical issue during an active session, with a notice explaining that time had been extended.
06 DESIGN FOUNDATION
Buy the foundation. Design what is specific.
There was no established design system when I arrived. As the product and the number of projects grew, maintaining every foundation from scratch would have taken time away from the product’s specific problems.
I established the design foundation, then adopted a purchased professional UI system, customised it for our products, and extended it where necessary. New components followed the same guidelines instead of becoming separate visual solutions.
The aim was consistency and faster progress across projects. The work was in choosing, adapting, and governing the system, alongside designing the domain-specific flows. Explore the design system approach ↗
07 DESIGN AS A TEAM PRACTICE
From the first designer to a shared process.
Initially I handled the design work myself. As UltraTone became more complex and other projects needed attention, I recruited four product designers. Two worked directly on UltraTone.
I helped translate technical requirements into design briefs, answered domain questions, reviewed proposals, and worked through alternatives with the team. Mentoring also covered how to run meetings, communicate decisions, manage time, and handle the pressure of presenting work.
Core service and account flows.
Cloud SIM purchase and the dedicated service, KYC, referral, top-up and vouchers, purchase history, callback, dashboard, call history, and buying credit. I also designed the initial profile version.
Later product areas and iterations.
Other designers contributed to calling, chat, conference calls, calendar, SIM settings, and a later profile version. I supported these contributions through design reviews and domain guidance.
A meaningful change was how design entered engineering decisions. Developers began checking proposed interface and flow changes with me before implementation, making design review part of the working process.
08 A DECISION I COULD NOT CHANGE
Not every capability needed to be built internally.
I recommended using an established third-party solution for automated identity verification rather than building an internal AI capability. My concerns were the specialist work involved, development time, cost, and the availability of mature alternatives.
The company chose an internal effort. According to my experience on the project, that effort did not deliver the intended capability. The product’s identity review instead operated through manual support verification.
That experience showed a limit of my influence: identifying a tradeoff and explaining it did not determine the final decision. The lesson was to make the build-versus-buy comparison concrete, including what the team would need to maintain after launch.
09 RELEASE & ORGANISATIONAL CHANGE
A working service, and a place for design.
UltraTone released capabilities in phases: Cloud SIM purchases and messages, VoIP and in-app calling, credit payments and top-ups, manual identity review, eSIM, and virtual numbers.
My contribution extended beyond a set of interfaces. I introduced a reusable design foundation, helped establish scenario-based collaboration with engineering, and recruited and supported a design team.
This case study combines original design files with my account of the work. Screens document the design work; individual iterations and recovery states are labelled where relevant.
10 REFLECTION
The timer should start when the person is ready.
The most important decision in the activation flow was a small one: notify the user when capacity returns, then ask for confirmation. Hardware availability alone was not a reason to start consuming someone’s time.
The same principle shaped the rest of the work. Separate buying a number from being able to use it. Separate activation allowance from physical capacity. Separate a team contribution from personal ownership.
In a complex domain, clarity came from making those distinctions explicit before turning them into screens.