DESIGN MANAGEMENT
4 MINS
Embracing subjectivity
Embracing subjectivity
as a Design Manager
as a Design Manager
Gayatri Ketharaman, UX Designer and Design Manager at Canvs, shares her reflections on doing both and why that dual role turned out to be the most natural path for her growth.
She joined Canvs to deepen her UX skills, but found herself managing teams while staying hands-on with design. For her, staying close to craft didn’t dilute her responsibilities as a manager; it strengthened them.
From approaching briefs with sharper questions to how developer handovers shape outcomes, Gayatri reflects on the decisions that shaped her style.
How it started
How it started
Around a year-and-a-half ago, I found myself craving a job that would let me grow my design chops and take more ownership of my work — this became my main reason behind wanting to work at Canvs. To my surprise, I was hired as both a Designer and a Design Manager. Excitement aside, I naturally had some hesitation, drawing from most of what I’d read, design management looked like something separate from design work. Managers weren’t supposed to be hands-on. Would this be the best place for me to grow as a UX Designer?
Around a year-and-a-half ago, I found myself craving a job that would let me grow my design chops and take more ownership of my work — this became my main reason behind wanting to work at Canvs. To my surprise, I was hired as both a Designer and a Design Manager. Excitement aside, I naturally had some hesitation, drawing from most of what I’d read, design management looked like something separate from design work. Managers weren’t supposed to be hands-on. Would this be the best place for me to grow as a UX Designer?
"Would this be the best place for me to grow as a UX Designer?"
"Would this be the best place for me to grow as a UX Designer?"
Sharpening my craft as a Design Manager
Sharpening my craft as a Design Manager
Sharpening my craft as a Design Manager
It really depends on the size of the project or feature. If I’m working on a small side project or building something that’s fairly self-contained, I usually just start directly with vibe coding. It’s quick, and I can get to a working version fast without spending too much time planning every detail.
But when it’s a bigger feature or part of a more complex system, I don’t go all in at once. I break the project down into smaller chunks and then use AI to help me build those chunks individually. Once I have those pieces, I integrate everything manually.
For me, AI works best as a way to get past the initial inertia. It helps me get a working scaffold in place. But as the logic gets more nuanced, I take over. I usually ask AI to help me build rough versions of each function, then go one by one and refine or fix them where needed.
For example, in a recent project, we had a state management logic tied to video segments. AI couldn’t handle that kind of layered complexity, so I used it only to get the initial draft, and then rewrote the specific interactions myself.
It really depends on the size of the project or feature. If I’m working on a small side project or building something that’s fairly self-contained, I usually just start directly with vibe coding. It’s quick, and I can get to a working version fast without spending too much time planning every detail.
But when it’s a bigger feature or part of a more complex system, I don’t go all in at once. I break the project down into smaller chunks and then use AI to help me build those chunks individually. Once I have those pieces, I integrate everything manually.
For me, AI works best as a way to get past the initial inertia. It helps me get a working scaffold in place. But as the logic gets more nuanced, I take over. I usually ask AI to help me build rough versions of each function, then go one by one and refine or fix them where needed.
For example, in a recent project, we had a state management logic tied to video segments. AI couldn’t handle that kind of layered complexity, so I used it only to get the initial draft, and then rewrote the specific interactions myself.
"A big part of the job is knowing your product and the best practices of your industry inside out, and using that knowledge to make confident, informed suggestions early on."
"A big part of the job is knowing your product and the best practices of your industry inside out, and using that knowledge to make confident, informed suggestions early on."
Design doesn’t have to start with a blank slate
Design doesn’t have to start with a blank slate
Design doesn’t have to start with a blank slate
There’s a prevalent idea in our field that you should never have all the answers at the beginning. In design school especially, people are taught to approach problems with a completely open mind — never jump to conclusions before doing the research.
While that mindset works in the early phases of complex projects, relying on a linear process slows things down when applied universally. In practice, starting with a hypothesis and refining and validating (or even disproving it!) as you go along makes work more focused. For smaller enhancements, being able to suggest solutions right off the bat builds trust with stakeholders and narrows the execution window to everyone’s benefit.
A big part of the job is knowing your product and the best practices of your industry inside out, and using that knowledge to make confident, informed suggestions early on.
There’s a prevalent idea in our field that you should never have all the answers at the beginning. In design school especially, people are taught to approach problems with a completely open mind — never jump to conclusions before doing the research.
While that mindset works in the early phases of complex projects, relying on a linear process slows things down when applied universally. In practice, starting with a hypothesis and refining and validating (or even disproving it!) as you go along makes work more focused. For smaller enhancements, being able to suggest solutions right off the bat builds trust with stakeholders and narrows the execution window to everyone’s benefit.
A big part of the job is knowing your product and the best practices of your industry inside out, and using that knowledge to make confident, informed suggestions early on.
Briefs are meant to be brief
Briefs are meant to be brief
Agencies can tend to treat the brief received at the get-go as their holy grail of knowledge. In reality, going beyond this initial documentation is what leads to the most meaningful solutions.
Often, the real “why” behind a request reveals itself only upon digging deeper. Our stakeholders have a larger pool of knowledge about their target group and project technicalities, and asking the right questions is key. This lets us investigate the brief, thereby opening up the solution space significantly.
Agencies can tend to treat the brief received at the get-go as their holy grail of knowledge. In reality, going beyond this initial documentation is what leads to the most meaningful solutions.
Often, the real “why” behind a request reveals itself only upon digging deeper. Our stakeholders have a larger pool of knowledge about their target group and project technicalities, and asking the right questions is key. This lets us investigate the brief, thereby opening up the solution space significantly.
Knowing how to talk about your design is as important as the design itself
Knowing how to talk about your design is as important as the design itself
There’s a maxim that’s often repeated in our field: “Good design speaks for itself”. That holds for end users, not for stakeholders. Knowing how to explain your design decisions effectively to stakeholders is easily half the process to get it across the finish line. Approach notes and/or design walkthroughs are a must.
Even with those, simply talking about what has been designed and breaking down the UI is rarely the best way to go about it. People need to know the reason behind design decisions and understand how different user perspectives have been considered to arrive at the outcome. Personalising your conversation so that your stakeholders get into their user's shoes, rather than just listing pain points, is often an easier way to keep people engaged.
There’s a maxim that’s often repeated in our field: “Good design speaks for itself”. That holds for end users, not for stakeholders. Knowing how to explain your design decisions effectively to stakeholders is easily half the process to get it across the finish line. Approach notes and/or design walkthroughs are a must.
Even with those, simply talking about what has been designed and breaking down the UI is rarely the best way to go about it. People need to know the reason behind design decisions and understand how different user perspectives have been considered to arrive at the outcome. Personalising your conversation so that your stakeholders get into their user's shoes, rather than just listing pain points, is often an easier way to keep people engaged.
The narrative should be flexible and contextual
The narrative should be flexible and contextual
In many companies, communication is more rigid, with set templates for briefs, presentations, and stakeholder updates. This helps consistency and is a safer approach. Everyone knows what to expect.
However, that convenience often comes at the expense of communication being contrived. Different pieces of design should have different narratives. Additionally, your stakeholders will have unique thought processes that should be catered to. Do they need a deep dive or just the highlights? Do they want to understand how we arrived at something or just the outcome? Will being anecdotal help the case, or waste time? Reading the room to answer these questions makes all the difference.
In many companies, communication is more rigid, with set templates for briefs, presentations, and stakeholder updates. This helps consistency and is a safer approach. Everyone knows what to expect.
However, that convenience often comes at the expense of communication being contrived. Different pieces of design should have different narratives. Additionally, your stakeholders will have unique thought processes that should be catered to. Do they need a deep dive or just the highlights? Do they want to understand how we arrived at something or just the outcome? Will being anecdotal help the case, or waste time? Reading the room to answer these questions makes all the difference.
"Your stakeholders will have unique thought processes that should be catered to. Reading the room to anticipate what they need will make all the difference."
"Your stakeholders will have unique thought processes that should be catered to. Reading the room to anticipate what they need will make all the difference."
Picking your battles
Picking your battles
Being the custodians of UX is often taken to mean always having the “best” UI solutions, and having those come into fruition. In long-term projects, collaborating to find the ideal solution, being open to ideas from every source and maintaining transparency are far more integral.
Context is everything. Is the feedback a legal necessity from compliance, a vertical trying to upsell itself, a technical constraint that cannot be circumvented, or something else entirely? Understanding the source helps you know what to push back on, what to adapt your designs around, and what to simply accept.
Being the custodians of UX is often taken to mean always having the “best” UI solutions, and having those come into fruition. In long-term projects, collaborating to find the ideal solution, being open to ideas from every source and maintaining transparency are far more integral.
Context is everything. Is the feedback a legal necessity from compliance, a vertical trying to upsell itself, a technical constraint that cannot be circumvented, or something else entirely? Understanding the source helps you know what to push back on, what to adapt your designs around, and what to simply accept.
Developer relations are a must
Developer relations are a must
A common quip in all design studios is the stark difference between what’s designed and how the final product ends up turning out. A lot of this can be chalked down to where the process ends in studios.
Building a bridge between design and development through tools, communication, and processes goes a long way. Basic knowledge of how to read code, coupled with specificity in pinpointing problems and potential fixes, works a lot better than just conveying that there’s an issue.
Utilising design and design management in reviews benefits all parties involved. Finding workable solutions to dev issues and taking calls on design consistency is faster; designers are more informed of best practices for future sprints; it’s a win-win situation.
A common quip in all design studios is the stark difference between what’s designed and how the final product ends up turning out. A lot of this can be chalked down to where the process ends in studios.
Building a bridge between design and development through tools, communication, and processes goes a long way. Basic knowledge of how to read code, coupled with specificity in pinpointing problems and potential fixes, works a lot better than just conveying that there’s an issue.
Utilising design and design management in reviews benefits all parties involved. Finding workable solutions to dev issues and taking calls on design consistency is faster; designers are more informed of best practices for future sprints; it’s a win-win situation.
"Basic knowledge of how to read code, coupled with specificity in pinpointing problems and potential fixes, works a lot better than just conveying to the devs that there’s an issue."
"Basic knowledge of how to read code, coupled with specificity in pinpointing problems and potential fixes, works a lot better than just conveying to the devs that there’s an issue."
Standard outcomes, subjective approaches
Standard outcomes, subjective approaches
Irrespective of your experience or the workplace, the “what” of the job is sacrosanct. You need to have the most knowledge in the room, be able to break down and scope out work effectively, manage time and expectations, and ensure you meet quality standards at all times.
The “how” of getting there is where the differences creep in. Finding ways of working that best suit your practice and the problems you’re trying to solve is a deeply personal and contextual process, and worth being thoughtful about.
Irrespective of your experience or the workplace, the “what” of the job is sacrosanct. You need to have the most knowledge in the room, be able to break down and scope out work effectively, manage time and expectations, and ensure you meet quality standards at all times.
The “how” of getting there is where the differences creep in. Finding ways of working that best suit your practice and the problems you’re trying to solve is a deeply personal and contextual process, and worth being thoughtful about.
Canvs is an interface design and engineering studio based in Mumbai, India. We are group design partners to some of India’s market leaders in Banking and Finance and have been around since 2016.