Map terminology, rules and dependencies.
BOLIAKU
DIDWW
Designing telecom products for desktop and mobile.
This was my first substantial product design role after university. Over two years at DIDWW, I helped translate complex desktop telecom workflows into mobile experiences and contributed to the design systems behind two different product ecosystems.
- 2021–2023
- UX/UI Designer
- Industry
- Telecommunications
- Collaboration
- Design Lead · Product · Engineering · Customer-facing teams
01
Understanding the domain
Learning the system
before simplifying it.
Telecom products contain unfamiliar terminology, dependencies and configuration logic. Before improving an interaction, I first had to understand what the system needed to preserve. The challenge was to reduce friction and inconsistency without hiding technical functionality that users still required.
Identify what someone is actually trying to complete.
Preserve capability while reducing cognitive load.
HOW I BUILT CONTEXT
Competitive researchWireframesFigma prototypesSupport ticketsCustomer-facing feedbackDesign reviewEngineering collaboration02
phone.systems mobile
Desktop logic.
Mobile priorities.
phone.systems already existed as a desktop product for configuring business communications. Together with the Design Lead, I designed the mobile product from the ground up around the tasks agents needed while actively handling communication—not a smaller copy of the desktop interface.
Call handling, history and dialing moved to the foreground.
Post-call notes could remain connected to communication history.
The product model remained familiar without copying desktop density.
9:41
AvailableSupport team
+370 6Lithuania
03
call.center mobile
Same telecom foundation.
A different audience.
call.center shared the communication domain but had a more expressive, engagement-oriented personality for smaller and local businesses. The mobile app prioritised agent activity, call history, teams and lightweight progress cues while keeping the mechanics recognisably professional.
WHY GAMIFICATION
Progress, rankings and achievements made repetitive agent work more visible and engaging. They were a product mechanism—not decoration or a claim of measured performance improvement.
TODAYAgent activity
72calls
LIVE TEAM
04
Design systems & product consistency
Maintaining the language
behind the products.
As the products evolved, I maintained and extended the design systems used across both. I updated existing components and contributed new states required by product work, helping desktop and mobile features remain coherent while collaborating with design and engineering.
05
How I worked
From problem
to product.
I worked closely with the Design Lead, who typically brought product problems and requirements. Within that context I had meaningful freedom to explore solutions, propose interaction patterns and initiate feature ideas where they strengthened the product.
Research and feedback were practical inputs: competitor patterns, support tickets, Figma prototypes, customer-facing colleagues, design review and engineering collaboration.
06
What DIDWW taught me
Designing complex software
for real people.
“DIDWW taught me how to turn unfamiliar, technically complex domains into usable product decisions.”
It was my first substantial product design role after university: where I learned to work inside a real SaaS team, own features from early exploration to production-ready design, and think beyond individual screens toward reusable systems.
Simplifying a product does not always mean removing complexity. Sometimes the complexity is necessary—the designer’s job is to make it understandable.