Today I'd like to introduce you to one of our community advocates Mikail Gundogdu. He's been a phenomenal supporter of our community since we started. He's currently working as a UX Designer at Clover Health supporting the design systems process.
In this interview, Mikhail sits down with RETHINK founder Julie Stanescu where he shares learnings on overcoming challenges as a first designer at a startup, how to set up processes around design systems, what were his strategies to influence stakeholders to adopt a new design system and tactics to stay organized as a solo designer while collaborating effectively with engineers and product managers.
What is your story and how did you get into design systems?
I come from a family of restaurateurs, but somehow I have always been drawn to technology. A couple of years ago while I was working at our family restaurant prepping food and providing IT support, I applied to Cal Poly in San Luis Obispo for computer science. My delight at being accepted turned into dread my senior year as my hope for entering technology hit a roadblock: I was not a talented programmer, and I was not sure that I wanted to be one anyway.
Fortunately, I had some internships under my belt that revealed I loved solving product problems and working with designers, so I enrolled in Tradecraft to turbocharge a transition to product design. It was there that I first heard about design systems and their role in bridging the gap between design and engineering.
Given my background, I knew I had to dig deeper. I created design systems in my projects as a learning opportunity, talked to design leaders about design systems, and attended any and every talk that had anything to do with design systems (shout out to RETHINK for hosting events on Design Systems). I was so obsessed, in fact, that I wrote a Medium article to tell more people about them.
What is your advice for setting processes around design systems while being the first designer in a startup?
Keep things simple. When I was working with Pay by Group we had to move at breakneck speeds with our limited resources. It was important that the system served our needs without overcomplicating things.
An example of this was how we documented our components. I initially tried Zeroheight because it was so pretty and an obvious choice. But in reality, every new tool means more time necessary to port work and switch contexts. I ended up just using Figma’s component descriptions to document components. This served our needs well enough while allowing us to move fast.
In short, have a bias for simplicity because small teams have a need for lean processes.
Documenting the design process at Pay by Group allowed us to land on a flow that worked for my team.
Design systems also act as an official reference document for a company or brand. What are your learnings on an easier onboarding of new team members to the design system?
Start with a mutual understanding.
Learn about each member’s experience with design systems. Try to ensure that you are aware of any apprehension or preconceptions they may have.
Learn their design strengths.
With that, you can effectively ask them to contribute to the design system. The system will be better for it, and the designer will have invested their own time into the system. Ownership goes a long way.
Establish a culture of feedback.
You may be writing the design system rules, but you are serving the needs of your team. Always ask for feedback and press for details to uncover problems. Do not forget to circle back with them; as changes to the design system are made, present your reasoning and address how you factored in their feedback. You might be surprised what benefits come with just being a good listener.
What are your strategies to influence stakeholders to adopt a new design system when having limited budget and time?
I always start by talking to my stakeholders about the existing problems. You identify the problem like inconsistency or inefficiency, and you communicate that to management. The process of building a design system is not so different from the product development process. The difference here is that users are internal - your team. That builds support, and the final product will end up better addressing their needs.
After problem definition, I continue involving my stakeholders early and often for feedback to iterate on. Some of us may be familiar with the “IKEA effect": a cognitive bias where users give greater value to a product they helped create. Again, having your users in-house makes this so easy that it cannot be neglected. In the end, the system will better serve your users and they will be invested in its success.
As you continue using and iterating on a design system, it is paramount that your system is so easy to use that designers have no choice but to use it. This means fitting the system into your team’s workflows without restricting them. The notion that design systems stifle creativity is a fallacy. If a designer finds themselves unable to apply creativity to novel solutions, your design system is failing. Design systems should exist to avoid repeated work, and in doing so will attract any human designer.
What are your tactics to stay organized as a solo designer while collaborating effectively with engineers and product managers?
Document everything
As the sole designer, you will not have anybody else to fall back on for insights and learnings. In documenting everything, be sure to use mediums that can be easily shared with stakeholders. Not everyone on the team may know Figma, so it cannot always be the best tool for collaborative work.
Create an effective plan
Systems design, creating a set of pieces that fit together, is especially difficult if you do not have some idea of how you will shape all your pieces when everything is finished. So create a roadmap and define your design system pieces at a high level to make working on individual pieces less of a crapshoot. If you find yourself revisiting work often, you may not be forming an effective plan.
Now in contrast, you’re at a larger company within a larger design team. How do you iterate and grow an existent design system in a more established company?
The biggest challenge I am facing is separating our design system aspirations from reality. For example, I jumped on pushing updates to our design system documentation before realizing that nobody really used it. This pattern repeated itself the more I contributed to existing pieces of the system. Now, I evaluate the effectiveness of a system piece before contributing to it, to decide if it would be better served by structural changes first.
That brings me to my first lesson. Do not be afraid to disrupt the status quo if you have done your due diligence. After learning about less effective aspects of our system, I proposed overhauls (with clear reasoning) that were met with team alignment and effective feedback. Timing was important here, too. I learned about our roadmap to align my proposals with a period in time that could benefit from and tolerate process revamps.
The last thing I want to leave RETHINK with is this: be a multiplier. Do your best at your own job, but jump at opportunities to help others with theirs. Doing so has built trust with my teammates, who now support my efforts to create our new workflows. Frankly, I did not learn this in my new role, but applying it early has paid dividends as I settle into design system ownership. After all, what is the purpose of a design system if not to help our teammates deliver their best work?
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Today I'd like to introduce you to one of our community advocates Mikail Gundogdu. He's been a phenomenal supporter of our community since we started. He's currently working as a UX Designer at Clover Health supporting the design systems process.
In this interview, Mikhail sits down with RETHINK founder Julie Stanescu where he shares learnings on overcoming challenges as a first designer at a startup, how to set up processes around design systems, what were his strategies to influence stakeholders to adopt a new design system and tactics to stay organized as a solo designer while collaborating effectively with engineers and product managers.
What is your story and how did you get into design systems?
I come from a family of restaurateurs, but somehow I have always been drawn to technology. A couple of years ago while I was working at our family restaurant prepping food and providing IT support, I applied to Cal Poly in San Luis Obispo for computer science. My delight at being accepted turned into dread my senior year as my hope for entering technology hit a roadblock: I was not a talented programmer, and I was not sure that I wanted to be one anyway.
Fortunately, I had some internships under my belt that revealed I loved solving product problems and working with designers, so I enrolled in Tradecraft to turbocharge a transition to product design. It was there that I first heard about design systems and their role in bridging the gap between design and engineering.
Given my background, I knew I had to dig deeper. I created design systems in my projects as a learning opportunity, talked to design leaders about design systems, and attended any and every talk that had anything to do with design systems (shout out to RETHINK for hosting events on Design Systems). I was so obsessed, in fact, that I wrote a Medium article to tell more people about them.
What is your advice for setting processes around design systems while being the first designer in a startup?
Keep things simple. When I was working with Pay by Group we had to move at breakneck speeds with our limited resources. It was important that the system served our needs without overcomplicating things.
An example of this was how we documented our components. I initially tried Zeroheight because it was so pretty and an obvious choice. But in reality, every new tool means more time necessary to port work and switch contexts. I ended up just using Figma’s component descriptions to document components. This served our needs well enough while allowing us to move fast.
In short, have a bias for simplicity because small teams have a need for lean processes.
Documenting the design process at Pay by Group allowed us to land on a flow that worked for my team.
Design systems also act as an official reference document for a company or brand. What are your learnings on an easier onboarding of new team members to the design system?
Start with a mutual understanding.
Learn about each member’s experience with design systems. Try to ensure that you are aware of any apprehension or preconceptions they may have.
Learn their design strengths.
With that, you can effectively ask them to contribute to the design system. The system will be better for it, and the designer will have invested their own time into the system. Ownership goes a long way.
Establish a culture of feedback.
You may be writing the design system rules, but you are serving the needs of your team. Always ask for feedback and press for details to uncover problems. Do not forget to circle back with them; as changes to the design system are made, present your reasoning and address how you factored in their feedback. You might be surprised what benefits come with just being a good listener.
What are your strategies to influence stakeholders to adopt a new design system when having limited budget and time?
I always start by talking to my stakeholders about the existing problems. You identify the problem like inconsistency or inefficiency, and you communicate that to management. The process of building a design system is not so different from the product development process. The difference here is that users are internal - your team. That builds support, and the final product will end up better addressing their needs.
After problem definition, I continue involving my stakeholders early and often for feedback to iterate on. Some of us may be familiar with the “IKEA effect": a cognitive bias where users give greater value to a product they helped create. Again, having your users in-house makes this so easy that it cannot be neglected. In the end, the system will better serve your users and they will be invested in its success.
As you continue using and iterating on a design system, it is paramount that your system is so easy to use that designers have no choice but to use it. This means fitting the system into your team’s workflows without restricting them. The notion that design systems stifle creativity is a fallacy. If a designer finds themselves unable to apply creativity to novel solutions, your design system is failing. Design systems should exist to avoid repeated work, and in doing so will attract any human designer.
What are your tactics to stay organized as a solo designer while collaborating effectively with engineers and product managers?
Document everything
As the sole designer, you will not have anybody else to fall back on for insights and learnings. In documenting everything, be sure to use mediums that can be easily shared with stakeholders. Not everyone on the team may know Figma, so it cannot always be the best tool for collaborative work.
Create an effective plan
Systems design, creating a set of pieces that fit together, is especially difficult if you do not have some idea of how you will shape all your pieces when everything is finished. So create a roadmap and define your design system pieces at a high level to make working on individual pieces less of a crapshoot. If you find yourself revisiting work often, you may not be forming an effective plan.
Now in contrast, you’re at a larger company within a larger design team. How do you iterate and grow an existent design system in a more established company?
The biggest challenge I am facing is separating our design system aspirations from reality. For example, I jumped on pushing updates to our design system documentation before realizing that nobody really used it. This pattern repeated itself the more I contributed to existing pieces of the system. Now, I evaluate the effectiveness of a system piece before contributing to it, to decide if it would be better served by structural changes first.
That brings me to my first lesson. Do not be afraid to disrupt the status quo if you have done your due diligence. After learning about less effective aspects of our system, I proposed overhauls (with clear reasoning) that were met with team alignment and effective feedback. Timing was important here, too. I learned about our roadmap to align my proposals with a period in time that could benefit from and tolerate process revamps.
The last thing I want to leave RETHINK with is this: be a multiplier. Do your best at your own job, but jump at opportunities to help others with theirs. Doing so has built trust with my teammates, who now support my efforts to create our new workflows. Frankly, I did not learn this in my new role, but applying it early has paid dividends as I settle into design system ownership. After all, what is the purpose of a design system if not to help our teammates deliver their best work?
GRATITUDE
People who support Leadership Circle
Deepest thanks to the following people who graciously offered feedback and support while beta testing Leadership Circle.
