2022 Professional Learnings

As 2022 comes to a close, here are 10 learnings from a designer in an early-stage SaaS startup building a product for design teams. The learnings come from two main experiences - being the single designer handling design execution for the product in the first half of the year, and then scaling a team and product in the second half. Here goes:

Learning 1: Ownership is taken, not given

Cubyts is my second ever job and second year as a professional designer too. While I had some experience working with engineers, PMs, and my design managers, up till that point I’d had the safety net of a senior individual overseeing my work. During the early part of the year 2022 as well, there was intense collaboration between my founders and PM (who are designers too) to thrash out the user stories, sketching the designs and finally supporting the PM in getting the backlogs defined for the engineering team. As the months passed, the management team had to focus on other business-critical issues and I lost my safety net. That pushed me to think holistically, and take complete ownership of all primary and edge cases. I delivered well in some cases and fell short in others, but I learned the tightrope of taking ownership.

Learning 2: Build a support system to fall back on

Our knowledge is based on our observations and our network. While I was designing core user flows for Cubyts, I was looking for inspirations, benchmarks, and ideas. Cubyts being a unique product itself, those were not easy to come by. What helped is the network. I was new to DesignOps, Design Management, and the entire space in general and had a basic understanding of design systems. I needed to deeply connect with our different user groups. Being a platform for the design team, it was easy to find help within our immediate circle of design professionals. So we built a network to discuss day-to-day questions like organizing a Figma file, building a style guide, knowing which components to add to the design system, prioritizing requirements, or validating ideas.

Learning 3: Good design is driven by a good understanding of business, tech, and product

Most of our requirements at this stage come based on feedback from our users and investors, as well as any usability and experience issues we face internally while using the platform. They are prioritized based on the value effort matrix and added to the design pipeline. But a lot happens, from the time a feature is designed, to when it goes into development, and then it’s deployed after testing. A new, more important requirement may come up, the developer assigned may not have the bandwidth, we may not have the tech in place yet to introduce the feature, and the team might relook at it and feel that something is missing. And even after being released on the platform, the feature might get shelved because it’s not telling the intended story when tied with other features. As a designer, you may be proud of something you recently worked on, and you’re excited to see it live. But it’s important to trust the team and the ecosystem, and the fact that someone is looking at the bigger picture, and at this moment, this particular intervention doesn’t fit.

Learning 4: Engaging with cross-functional teams brings coherence

Drawing further on the previous point, life is better when you have a good relationship with other teams. With development, keeping them in the loop when we’re finalizing certain concepts gives them clarity on what’s coming up and how they can prepare for it. They might have suggestions on an easier way to achieve the same interaction or possible edge cases that might occur. With product management, working hand in hand keeps both parties aware of the requirements and gives a platform to discuss concerns, constraints, and timelines. Being in contact with marketing keeps us in touch with the feedback we’re receiving and what the market expects, gives a reality check and pulls us out of the bubble of design.

Learning 5: Hiring is a slow process

In Feb of this year, we started a fresh set of hiring initiatives hoping to close them by April. The new members of the team joined in August. This was my first experience being involved in hiring. From posting the first JDs on LinkedIn and getting almost no responses due to the lack of activity on our profiles, to conducting interviews and reviewing assessments, the entire ordeal was an lengthy one. Finding people who meet your requirements in terms of experience, maturity, openness to changes and feedback, matching the wavelength, willing to get their hands dirty and design, was not an easy thing to do. Having a network helped here too, as you’re more likely to trust a referral coming from someone who knows you, your company and understands your requirements.

Learning 6: Making decisions with the goal in mind

This is a more personal observation that I saw within myself and many other members of the team. Maybe it goes to say that we’re passionate about the company and its vision. But I noticed a lot of us thinking and making decisions, sometimes even personal, keeping the vision of the company in mind. Whether this was in deciding to hire for senior roles vs junior roles, transferring responsibilities to someone who might do the job better, rescheduling vacation dates to times that were more convenient for others, collaborating with freelance consultants after hours because the only time they were free was late on weekdays and on weekends, many of us were considering the long term gain of the company before making short term decisions.

Learning 7: It’s important that the core team is passionate about the problem

As a designer, I’ve had a lot of fun building a design platform. I’m solving operational challenges that I face or have faced in previous projects. So it was fairly easy to get me to be passionate about the problem statement, and the same goes for the rest of the members with a design background. For the rest of the team, this could be like building and marketing any other platform. I remember a conversation with a colleague (developer) where he asked me, “what is it about designers? What’s so different in the way you work that you can’t use JIRA?”. Not everyone had the same understanding of the product and its need. If they don’t understand it, they can’t be passionate about the problem, so why would they put an extra effort to go the extra mile when needed? This is honestly an ongoing exercise for us. But some of the efforts we took have made small differences. We started conducting co-ideation workshops with the entire team, from defining a problem statement and its use cases, to sketching ideas, to discussing solutions that worked. The point wasn’t what the solution was, but the fact that everyone was involved in the process. We also conducted knowledge-sharing sessions about the research process, collecting insights and turning them into solutions. There were design system talks, where we brought in people to talk about challenges from both sides. When critiquing the front-end team’s execution, it wasn’t just that this spacing is off or the colour doesn’t match. We made efforts to make developers identify issues bigger than just pixel inconsistencies. This led to some delightful instances of them pointing out inconsistencies and suggesting solutions, suggesting cool references for certain interactions, critiquing usability, and in sometimes being willing to go above and beyond to achieve an experience when the built version wasn’t up to the mark. There’s something really wholesome about that.

Learning 8: Every conversation is important

As the designer responsible for all output, every single conversation you have is one in which the other person is giving feedback. With the founders, it’s problems with experience, with the PM, it’s what more can we do, with developers, it’s about inconsistencies or why something doesn’t look as good as it did in design, with users its problems. While all of these are constructive criticism and always meant with an intent to improve collectively, so much criticism in a day, and everyday can feel like a lot. It took a considerable amount of letting go and acceptance to realise just like the product, every feature is in an MVP stage and will only improve, and to welcome it. It also led to the realisation that it’s easy to critique and improve a design, but to visualise something from scratch that conveys the initially abstract concept, factoring all the dependent features, is a big challenge but a fun one.

Learning 9: To set up a startup, you need generalists. To scale, you need experts.

Up till 6 months ago, 70% of the team members had joined with 1–2 years of experience. At the time, this helped because everyone was able to assume different hats to figure out a problem and get moving with it. However, this involved a lot of trial and error. The platform was new to everyone and selecting what controls to use or what method to use involved multiple POCs, testing, time, and learning. After our seed funding, when we started our hiring cycle, we took a decision to look for senior roles. We needed people with experience to steer the ship and help make faster and informed decisions. While this brought in an extra level of hierarchy, we needed to do this to scale the right way. That has led to quick optimization on multiple fronts, in buildings the Design System, improving the front end, defining handover processes, making infrastructure overhauls, and having templates for marketing, in just a few months. Today, the average experience level has increased to 4–5 years, and we’re stronger foundationally.

Learning 10: Change is a constant and adapting to it is the key

At times in a startup, every week brings a new surprise. You can be midway through your work on a feature and you have a conversation that brings a new perspective, or certain technical constraints on your idea might arise, an investor or users voice new feedback that takes priority, or a recession kicks in and your feature was a good-to-have, not a need. Any of these can force you to abandon your current work, change the scope completely, put it on hold, or hand it over to someone else. These things are easier to do when you’ve built a level of detachment so you’re not affected in case you have to pause on something you’d put a lot of effort into. The ability to work flexibly, accommodate change and adjust according to the situation makes your job as well as others’ smooth.