Undergoing digital transformation with Singapore's biggest telco


Timeframe: 2015 - 2017
Role: (2015 - 2017) UX designer in a design team of 6 -- (2017) UX lead following previous lead's departure

Type: Transformation across digital touchpoints
Status: Launched & live
Visit: singtel.com

Refreshed screens for Singtel.com

⏱ project overview

In 2015, Singtel started an organization-wide digital transformation process. As the biggest telco operating in Singapore, Singtel serves 4.1 million subscribers across mobile, broadband, and television services.

As all digital transformation programs go, ours was a long and challenging journey. Amidst these challenges, we ran our user-centred approach and process through an 8-week discovery phase, where the team was allowed the luxury of time to set up the foundational design principles, run research, and gear up for the development phase.

The team then worked with product owners to gather requirements and designed the baseline digital design framework for the organization on a new billing and CRM system. Alongside translating the new brand style guide, Release 1 took place across 15 sprints of our collective hard work.

πŸ’« Impact


portals into 1 unified site, including bringing TV onboard for the first time since 2004


individual pages with differing styles into 20 standardized key templates


improvement on Customer Satisfaction Score

Key learning #1

Design doesn't belong in a silo

I know. Isn't this obvious, you ask?

Picture this: an aura of pomp for this individual contributor, two projects in with their "proper" UX role at Singtel, having shipped out an e-commerce product and a refresh of one of the most used utility apps in Singapore in the months prior.

They've read everything (narrator's note: not everything) on the internet about the magic of design thinking, and how design is going to change the world, and why design deserves a seat at the table!

I think we all can see where this story is leading.


To say that being on this digital transformation also pushed me (some might say shove) into maturing as a designer would be an understatement. It wasn't just the craft that I was learning β€” if not every day, then at least something new every week β€” but also maturing into a more thoughtful designer and person.

I can confidently say that I work at the intersection of the user, the business, and technology, but the confidence has definitely built over the years. There was definitely grumbling about the rigid and ridiculous requirements the business came up with, or how annoying it was that the developers couldn't do something we wanted in the time that we had.

I understand β€” now β€” that keeping everyone aligned is our job, but to that brash, idealistic designer back in 2015, there was a sense of frustration where every pushback seemed like a massive roadblock.

The state of the current

Governance. What governance? Each page, site, and portal was outsourced to external agencies to manage, with requirements driven by each individual team with no real overarching view of what the other is doing.

Here were the product stakeholders we collaborated with:

  • Customer operations (across all touchpoints)
  • Sales (the physical stores, as well as the online store, known colloquially as "e-shop" β€” perhaps a signpost of how old the term is now!)
  • Product (think roaming products, rather than the tech-world products we are more used to)
  • Mobile marketing and communications
  • Customer loyalty/relationship
  • TV & Broadband
  • Finance
  • Corporate communications
Diagram of a massive, sprawling ecosystem of websites, pages, and systems that don't talk to each other

Pictured: A massive, sprawling ecosystem of websites, pages, and systems that don't talk to each other

In a word... messy.


Portals and microsites users have to visit to get their needs fulfilled


Levels of hierarchy to navigate to view information on products and services


Lack of unified information architecture and content structure that makes it difficult for users

The pitfalls of operating in silos were always apparent. We've heard stories - lots of them. Here's a sample:

  • Conflicting product promotions because the mobile business didn't know that the TV business was pushing a promotion that was 95% similar, at the same time
  • Operations staff having to check at least four different systems to get information because they were stored across multiple platforms - all while being on the call with the customer
  • Various teams working on similar tasks with overlapping outcomes because of each teams' different KPIs
  • The inability to update the site in a timely manner because of the long wait with IT, thus losing out days or weeks to the competition because consumers would hop around looking for the best deal at that specific moment

Of course, the digital transformation wasn't going to solve all of these problems on Day 1, but it would be the first step in the right direction. 

Making sense of a new chaos

Or: the activities I ran:

Before the sprints

Discovery is definitely an area I wish we could've spent more time in, though not too much β€” there is always a delicate balance between diving too deep into a hole, and being able to come up with usable and actionable insights for the development phase.

Discovery workshops & stakeholder interviews


The power of foresight to ask someone to take photos of me running a workshop was never my strongest suit!

I went from supporting my team lead in conducting discovery and prioritization workshops for stakeholders across the different departments of the consumer business, to leading them by the time the program reached its subsequent releases.

Content inventory & information architecture

A sample of the IA, which feeds into the navigation

A sample of the deeper IA, which feeds into the navigation and site map

We did a content inventory of the existing site, before coming up with two options for the IA:

  • Shallow and wide, with all products and services surfaced on the first levels, or,
  • One that is slightly deeper, with an umbrella called "Products" to house said products and services.


User testing: Reverse card sorting


Pictured: An abysmal success rate for what is arguably the most important line of business 

With the two IA options, we ran a reverse card sorting with ~200 users on Optimal Workshop. The results were humbling, seeing our hypothesis β€” that the shallow and wide one would be the easier option to navigate β€” being invalidated almost instantly.

There were also people who breezed by all the tasks in 2 minutes, and not surprisingly, got a near 0% success rate β€” was it a lapse in recruitment? The test setup?

I wish we could've captured more insights from these participants through a later round of user testing, but alas.

Design principles, established:

An initial set of "design attributes" were identified at the start of the project, which were then used to facilitate 2 activities: concept testing with 300+ users, as well as stakeholder workshops. These attributes were then ranked from both activities, and used to establish these design principles as our guardrails.


Focused, contextual, personalized


Friendly, warm, inviting


Clean, intuitive, organized


Dynamic, interactive, immersive

During sprints

I won't bore you too much about what we did in the agile process (though, we'd often joked it's a fr-agile one, so!) that we ran 15 sprints, then a few more in the next release in, but suffice to say that I am a well-trained agile practitioner who can work very well under very tight timelines:

  • Sprint planning
  • Requirements gathering and story grooming
  • User flows and wireframes, with purchase flows streamlined and optimized across product lines to provide a unified experience
  • Syncing up with the visual/UI designers to translate wireframes into screens, then eventually a prototype
  • Syncing up with the BAs and developers, and coming up with a review framework to make sure that nothing falls through the gaps
  • Interaction and design documentation (also known as a design system before it was known as one)
  • Coming up with a QA process, so that all defects were readily called out and documented

An interesting thing that happened

While in the midst of our designing and developing, StarHub released a new account management portal out of the blue! We had to scramble to do a mini-competitive analysis, comparing it to what we were building to assuage the stakeholders' anxiety. 

Key learning #2

Learning on the go is the key to this long marathon

To say that I was on a steep learning curve would be an understatement. While I had multiple projects under my belt at this point, this was still one of the bigger projects of my career thus far, and it was an impactful one that millions of subscribers would need to interact with. 

Looking back, I'm grateful that I had this opportunity to really go deep into my craft and expertise, and come out the other side a more mature and skilled practitioner. There were plenty of "firsts", and all of it required some nimbleness and swiftness in absorbing knowledge before executing them.

DesignOps, before it got a cool name

Lack of tools, templates, and processes shared universally made our lives harder than it should have been:

  • Research: Powerpoint, large video files, Powerpoint, PDF exports, and did I mention Powerpoint?

  • UX design: Powerpoint (yes, for some documentation of flows and wireframes!), but mostly Axure RP, which we uploaded to the cloud service so everyone across the teams had access to flows and wireframes, mapped painstakingly with epic names and user stories.

    There was also version control on every single page for all the changes we made in every single sprint, as well as overall release notes.

    Verdict: 0/10, would not manually do this again.
Screenshots of the release notes system within the wireframes

Left: The abomination of a Frankenstein's monster-ed overall release notes
Right: Release notes on each specific screen so that there was an accountability chain

  • "Mobile responsive" wasn't even part of the actual scope, but something we had to fight for additional time to deliver right.

  • Visual design: Dark times in design history as Photoshop was used for UI designs

I'm so thankful that we now have an embarrassment of riches with our tools, frameworks, and systems to adapt from πŸ’

A scalable design system

We spent a good chunk of our time after the Release 1 sprints trying to get our documentation for our components up.

The year is 2016, and the only points of reference the design community at large had was Google's Material Design, and a handful of other design systems (Design language? Digital style guides? The industry at large was still deciding on taxonomy.).

This meant that we had to start our repository from scratch. Because our UI files lived in Photoshop, it wasn't the best use of our time to recreate things in Sketch.

Instead, there was a concerted effort to identify critical components that the development team needed, so that we could prioritize which ones would get recreated and ported over to Sketch for a more unified and scalable view of our entire system at large.

Documentation on a Google Sheet

I couldn't find the actual components library, but here is some evidence of the documentation and tracker we used...

Were there things I would've done differently, given what I know now? Oh, heck yeah. Obviously, we would've flipped the whole process, and established the design system as a building block, rather than something we had to do at the end.

It was, as things were in this project, a learning curve that I absolutely enjoyed, and have taken to go more in depth for my future projects.

Key learning #3

Avoiding the UX theatre is a tricky dance

...and unfortunately, a dance that I had two left feet for at that moment in time.

Lack of usability testing and other research

While we were able to do some research on this whole program, the volume was definitely not appropriate for something as large as this. I wish we had the time and budget to do user research through interviews in the discovery phase, but even more than that, I wish that we were able to do consistent in-sprint usability testing of our wireframes.

It would have been even better if the product owners could shape their vision through actual user insights, rather than putting themselves in the shoes of the users, to make their best estimate of what they would want. 

Thankfully, as I rolled off this project, I was able to take my newly-learned management skills to gain confidence in being an even more vocal advocate, and was able to run a better, iterative process in my next project (the Prepaid app redesign).

Accessibility as an afterthought

Looking back, I cringe completely at the lack of depth in my knowledge of accessibility. While basic color contrast ratios were met, there wasn't an advocate for accessibility, and it only got picked up (though just barely) during the development stage. 

Taking the 'easy' way out

As a team, we went for the obvious, "easier" way, because the strategy was to get everybody on board and aligned to a bigger vision. "Changes will be made after the launch"... it's been 5 years since.

Entire teams that were not involved during the first release had additional requirements that challenged the scalability of our designs - as the saying goes, we don't know what we don't know, and it made it hard for us to anticipate these changes despite our best efforts.

We also let go of some fights in view of the bigger "battle", such as agreeing to the usage of carousels under pressure from the marketing team, despite us knowing that they are not effective as an interaction pattern. Or taking in last-minute requests for a user base of one, because they are connected to somebody who knows somebody. 


This took me a long, long while to write (it is now 2022, and I'm putting the finishing touches to something that my involvement ended in 2017). A lot of it is the inertia to document such a massive project, knowing that I was going to miss things β€” and I am sure that I have! β€” and that, as time went by, I was going to lose access to documentations, repositories and the likes. More than that, the memories have started getting fuzzy, but I do remember the good times the team had together through it all.

But, I'm glad this is finally somewhere in the digital land right now, where it will remain as a time capsule. This was a project that I'd grown so much in, and withο»Ώ. It was a massive opportunity and I'm proud of myself for taking on new roles and responsibilities, and it has given me a much-needed perspective in my current workplace, given that digital transformations are the bread and butter of what I do now.

Something about full circle, I think.