Improve team experience working on Techcombank Design System

Role
Design System Lead

Company
Techcombank

Hanoi 2022

✱

In less than 4 months, our Techcombank Product Design Team (PXD) had built from scratch and launched the MVP of our first organisation design system, which fostered real-time collaboration among 5 multi-disciplinary product teams on a daily basis. This is about the post MVP where we relentlessly optimize the system in order to spend time thinking about high level UX problems instead of mindlessly repeating busy work.

Background

Before 2021, there was no design system in Techcombank. From the very first ideation to production, designers had to switch between 4 tools for wireframes, design, prototyping, and handover. There was no such thing as version control and real-time collaboration, which resulted in high effort, low consistency, and poor user experience.

Starting of 2021, along with the redesign of our omnichannel experience for both retail and corporate sectors, we migrated all assets from Sketch to Figma and initiated the organization's first family of design systems, which successfully engaged with 9 product teams across 3 platforms (mobile app, web app, website).

Sounds like a happy ending? Well, we’re not there yet…

The status-quo

The underlying structure of Techcombank Design System family

Our design system was not just a single style guide. It’s actually a family of design systems, managed by distributed teams, each including design and documentation. The idea was to de-centralise the building and maintenance of each system to the product team so that it serves the particular experience, service, and business model.

However, we faced several problems after teams defined the experience journeys and started to build prototypes. Designing at scale, across multiple products, projects and scrum teams turned the design system into a messy workspace with several conflicting components and indistinct patterns. We heard complaints from time to time, like:

😩️ “It takes so much time to find the thing I need! Where is your file in again?”

😰️ “Hmm, I am not confident that this component is ready to use.”

In the long run, this might end up in poor quality customer experiences, brand dilution, and production inefficiency including slow time to market, lost assets, and of course, sad and burnt-out designers.

Finding the root causes

A bunch of designers assembled to conquer the issues, with the goal of better-structured and highly discoverable design system assets, including projects, design files, templates, patterns, and components.

First step: reality check. We listed our hypothesis behind a messy, inconsistent design system, what we thought we know, or what we didn’t know at all. The best way we could find the answers was to talk to our primary users. We sat with 10 designers, copywriters and developers in order to know their stories, their current behaviors and pain points working on the design system.

The research covered 7 themes: Seniority and experience, Tool literacy, Design system understanding, Daily workflow, Confidence, Worry & Fear, Closing the gap.

Here were what we found out:

The current design system file and library structure (on Figma) is complicated, hard to discover, and oriented without guidelines or direct instructions. Even once the designers got familiar with it, they found it hard and take time to navigate.

People have limited experience working on an organisational scale design system that links to several products across platforms. In addition to that, there was a gap in tool literacy.

The assets (templates, patterns, and components) discoverability was low due to poor naming convention.

The lack of guidelines and instructions resulted in poor design decision-making and time-consuming.

Solutions

We brainstormed several solutions to the root causes, and selected some to implement using prioritization mapping, taking into consideration our biggest technical constraint, which is the way Figma structures teams, projects, and files.

📂 Rearrange the Team Structure on Figma

People usually search by feature or journey name and tend to work on a single file instead of moving designs between Sandbox and Ready-for-dev space. Therefore, grouping similar features and journeys into a theme enhances searchability. The work progress is also more simple and transparent, when scrum team members, from designers, POs, BAs, engineers, and QAs all access in 1 file.

In fact, we tested this new structure with 10 users before rolling it out to all the team, and the discoverability and learnability were significantly increased. A user like our new UX copywriter could navigate in our system smoothly in no time.

🗓 PXD Saturday Workshop

Our PXD team hosts a workshop biweekly for all team members to discuss the design system way of working, introduce new patterns or UI components and their guidelines, and share with each other the pro tips and cool plugins.

All the impediments, constraints, or feedback are considered so that as a team we keep iterating.

📰 Design System Newsletter

Since our system is more about human experience than just only technical specs, we acknowledge that the time we invest in relationships with designers and engineers, business teams, and stakeholders is as important as building the system itself. That’s why we start sending out the Design System Newsletter fortnightly. That’s why the goals for our Newsletter go beyond our archive of work and UI spec that only some designers care about.

With each issue of the Newsletter, we want to:

Make sure our work is transparent
Guide people about the system and how they can contribute to it to make it useful for the rest of the organisation
Create a common language for our system
Show how we tackled customer experience with our system so that people can see the scale and breadth of our work

We often have this joke that the design system is never done. Publishing the Newsletter is a nice thing since we start to feel accomplished and gain motivation to move forward.

Enjoying our self-actualising moment of getting things done.

Results

We have witnessed a significant increase in the number of members using the system for their daily work since our very first enhancement. 100% of members from 17 multi-disciplinary product teams access Figma for design, feedback, development and testing. Aside from the Digital Office, we also welcome members from other departments like Marketing, Digital Sales, etc., for design assets and real-time collaboration.

Things to improve

Naming convention: The discoverability is one of our design system’s key success, and we know it can be improved starting with a clear taxonomy of naming convention. We try to avoid using long technical jargon to name our patterns or components, but to highlight their functions instead, so they match with the mental model of our designers.
Design for experience: As the system scales, we have more and more defined components that combine into templates. The series of templates and screens make a customer experience. By refining those, we can boost consistency and save the effort of our designers in decision-making. At the end of the day, what designers want is to build prototypes and have them tested with customers as soon as possible, not trying to figure out how to use colors on a screen by reading 5-page length guidelines.

Success metrics: The more we enhance our design system, the less effort people will spend on the development phase. In the near future, we will add a set of metrics to measure the effort saved, for example, the reduction in the number of changes and design bugs.

Conclusion

Design is thinking made visual. Techcombank Design System is where we systemize our thinking and decisions with visual language in order to optimize the team's effort and deliver the best experience to our users.

Experience hierarchy in terms of Techcombank Design System: From business model and outcome to user experience, and finally human effort optimization.

Though there are no dedicated product owners and designers, with that vision in mind, our team constantly strives to enhance the design system. After each improvement, we successfully deliver our solutions faster, be more transparent to non-design roles, get buy-in from our stakeholders and increase the number of happy designers across the universe.

Are we still arguing why design matters?

29 Mar 2022 Thinking about design thinking in business for digital transformation, from a product designer’s perspective

Cover: THINK. Paul Rand’s popular Eye-Bee-M poster, a type of word puzzle known as a rebus that uses pictures to represent letters, was created in 1981 in support of IBM’s motto, THINK.

It is 2022, why are we still arguing the business value of design?

Have you ever tried so hard to articulate the reason why design matters to your colleagues? Have you ever felt desperate whenever someone on your team aggressively undermines the idea of design thinking because "it only works in theory"? The worst thing is, even you have a vague doubt of this approach as well?

The moment I wrote this down, I could recall my picture back in early 2020. Working as a UX designer in one of the market's finance giants, I walked into any design workshop in defense mode: I always made sure to be well equipped with lots of Post-its and Sharpies, running the workshop format in my head, hoping I could make my team feel engaged and encouraged to give out many ideas as possible. I did not expect much in return though. Hard as I tried, I often found myself gradually losing my patience along the way, unconsciously sighed a lot, secretly eye-rolled sometimes, and at the end, walked out with much disappointment. "Will it be much easier if I have done it all by myself? Should I?" - I wonder, from time to time.

Back then, I knew my disappointment came from my own expectation, that it was 2020, and Design Thinking was DEFINITELY a thing. It is no longer a matter of aesthetics or corporate images on the marketing campaign and email templates.“Today design is widely acknowledged as a C-suite concern and a key element of corporate strategy.” In my institution, this mindset of Design Thinking had been communicated at an organizational scale, breadth and depth, as one of the most focused initiatives in the same year.

Then why do people still unhesitantly show their doubt about that?

Design Thinking is not that new

It is a common misconception that Design Thinking is new. Design has been practiced for ages: monuments, bridges, automobiles, subway systems are all end-products of design processes. Throughout history, good designers have applied a human-centric creative process to build meaningful and effective solutions.

The sitting experience. 1956 Promotional Film of
The Eames Lounge Chair Assembly.

I can roughly guess why many people make the same misunderstanding. I have enrolled in several courses and trainings in design thinking, rarely any of them did mention this side of history.

As we all know, Design Thinking has been engaged in "transforming" strategies by many enterprises, ones that switch from product-centric to user-centric approaches. However, in Daniel Kahneman's "Thinking, Fast & Slow", readers get to know the fact that in enterprises, many people perceive "re-organizations" and "restructuring" as losses, and since "losses loom larger than gains", they will be more active and determined to protect the enterprises' status quos. (3)

I quickly link these biases to the struggle of many large enterprises on endorsing Design Thinking. Though it remains an unvalidated assumption, people may refuse to change their mindset due to organizations evangelizing Design Thinking as a vague, abstract idea that at first doesn't offer credible outcomes.

A new hope

Digging deeper and deeper into the problem trying to find an answer, I found this Internet gold: Phil Gilbert, IBM General Manager of Design, shared about how he and his team at IBM had been changing the enterprise's culture at its core. (You can find the link to the speech at the end of this article.)

“We don’t go around IBM evangelizing design as anything good in the abstract.”

A focus on user outcomes

Phil started his speech convincing the audiences that hard as it may seem, it only takes 1 millisecond to change one's mindset.

If you have enrolled in the IBM Design Thinking course then you are familiar with this exercise. First, grab your Post-it and pen, and try to "Design a vase". Then, think about designing a better way for people to enjoy flowers in their homes.

This example gives participants a simple and clear definition of "experience". It points out the obvious difference between a product and an experience, which in the first place is unclear to many people. Focus on what is called "user experience" is the key point of design thinking, to avoid building another product that users don't want or need, the experience that differentiates your services in the marketplace.

Diverse empowered teams

In the early days of my career, I had heard this statement every now and then, that "A UX Designer is here in our team to represent the voice of users". At that time, it did sound true. However, this kind of thinking may de-leverage the power of a multi-disciplinary team that shares the same focus on user outcomes. It somehow reflects the waterfall mindset where designers spend most of the time in an isolated space focusing on their craftmanship.

Nevertheless, as designers and design thinking practitioners, we spend a lot of time communicating with our team members, each of them owns such different background and skill set. Therefore, it is crucial to make sure that our team shares the same definition and understanding of a subject or a problem and articulate their argument to people that may not have our point of view.

Restless reinvention

For designers who are reading this, I know you all once had that “I-am-fucking-done-with-this” moment when your PO told you to change your visual design because it looked off somehow, when your SA asked why didn’t you just simply copy your competitors’ design regarding the feasibility, or when the legal team insisted to throw the law jargon at users because to them it’s illegal not to do that. Well, slowly take a step back at the above-mentioned definition of experience. It takes only 1 millisecond to change one's mindset on experience design. However, it may take a little longer to actually show people how to act on that new change and turn them into believers.

The tech giants have proved it for us: The best way to change people's mindsets is to work constantly and prove the efficiency of the outcomes.

Lessons we learned along the way

I found myself in such kind of relief after watching Phil’s speech. Seems like constantly practicing design thinking and proving the outcomes to the team is not only my own challenge against UX immaturity but also the same challenge I share with many designers out there, even in Silicon Valley where they have several decades adjusting and testing the framework.

Of course, fostering a culture of makers and nurturing creativity is a huge challenge to any design leaders and executives in big organizations. Regardless, as a designer and design thinking practitioner, I keep reminding myself of those lessons that I have the opportunities to observe and learn from the best ones:

For all of us designers, change management is job one. Changing mindsets, getting people to understand the value, are things that are built on true practices from the business world that we can leverage.
Communication is key. You have to articulate your argument to people that may not share your point of view.
Be patience. You can’t win people’s beliefs by telling them they are wrong and have a fixed mindset. Try to understand their point of view as well.
Stop evangelizing design thinking as a vague idea. Prove the efficiency with the outcomes.

I truly hope these are somehow helpful for any young designers struggling every day with UX immaturity at work.

Thanks for scrolling. I would love to hear your thoughts and discuss, so you can leave it on my Medium site by tapping here.

Wishing you a nice day 🌤