Moving design from a service department to
a product function
Product Design is people-to-people work, even when we’d sometimes rather retreat to a quiet corner and focus on creating the perfect interface. Today, AI can sketch a prototype in minutes, making our greatest value helping teams understand the real business and user problems behind requests and feedback.
In my experience, teams still see us as the "make it pretty" department. That perception hurts morale and product outcomes: it leaves us feeling that we’re not delivering meaningful value, and a polished UI can’t fix a broken product.
So, this may look like a design problem, right? Let’s explore how to solve it.
Context
I started at Inbank as a B2B and D2B product designer and Design Lead during a tough time. The company was going through a reorganisation, the previous Design Lead was leaving; new products were launching, and everyone was rushing.
Even though we had a design system, clear brand guidelines, and regular meetings like weekly sync-ups and reviews, these didn’t make much difference. The team still felt left out, unmotivated, and disorganised.
Impact
In my last two quarters, I saw the quarterly plan before the quarter started — and could shape it. Not fully fixed, but design was finally in the room.
Solution
To understand the bigger picture, I worked across two products: the Partner Portal, used to sell goods through Inbank loans at points of sale, and Back Office, which supports processes, product setup, and decision-making. Collaborating with product and design teams, I saw Inbank as an interconnected ecosystem—not a set of separate B2B, B2C, and internal products.
Our shared goal was to make using Inbank loans seamless and deliver a consistent product and brand experience. Success depended not on team morale or my performance as a manager, but on strong, consistent outcomes for customers.
Educate
Fortunately, people at Inbank are eager to learn, so I ran a few “How to work with designers” workshops for product owners. In these sessions, I used a whiteboard exercise to show that most of the design process is about research and discussion, not just making things look nice.
Involve design team into planning
I spoke with Product Line Leads and managers, asked about their quarterly plans, and negotiated time for design initiatives and improvements that my teammates or I thought were useful. I also explained how design should be part of the development process as its own activity, including research.
Prove it in my own work
I showed this in my work. While building features for the Partner Portal and learning more about the product, I suggested a Partnership management platform that brought in new users and helped lower operational costs for the back-office team. See the case →
Give engineering a win
Being involved in planning helped to establish better collaboration with the engineering team. In the Partner Portal team, I tried out “dopamine tasks.” The engineering team set aside 4 hours each sprint for UI improvements—small changes that improved the user experience without requiring major technical changes. This didn’t overload the engineers, but it improved the user experience, gave designers more room for their ideas, and eased tension between designers and engineers. After a few months of success, we expanded this approach to other teams.
The throughline
I worked in situations where teams did not know how to collaborate with us. I managed negotiations by arranging for someone else to help, and I did the product work myself to show how it could be done. It was the mix of these actions, not just one, that turned the service department into a product-focused team.