Kenneth Mark Dsouza — Writing

The design process is dead, long live the design process

Mon, 02 Mar 2026 00:00:00 GMT

Over the last couple of decades, people have tried to tame and commoditize the design process into a neat package especially in the software startup world.

This in-turn had led to designer portfolios filled with a templatic story of research, personas, wireframes and final output[^1]. A predictable sequence manufactured (often in retrospect) to appease the hiring manager gods.

The design process was never about following a linear sequence. It wasn't about the artifacts or the rituals. It was just easy to market it as such.

The real design process was about making, testing, failing and learning – all in the quest for a better human centric product. It's far easier to build products and features by targeting "low hanging fruits", looking at what the competitors are doing, or favouring your CEO's bias. Much easier than going out to talk to your users, dissect your product’s data and figure out what you really need to build. After all, the cost of bad product decisions is only visible in hindsight, while the cost of user research is visible upfront.

But when you are building products for users who aren’t like you, there is no replacement for the process.

At Jiva.ag, we were building for rural Indonesia. Our users weren’t digital natives but often humans with limited technical literacy. We couldn’t really design products and systems for them sitting in our AC offices. We needed to spend time with them – mapping their world and understanding their ways. We tested with scrappy prototypes, iterating upon and validating ideas until we sat down to build. That’s how we understood how our customers used the internet, how they made decisions, and what mattered to them.

Yes, AI can help close the loop faster. But without a process, we would have designed for ourselves and not our users.

[^1]: or beautiful dribbble UI or excessive animations that would frustrate the average user [^2]: "Design fixation is a well-documented cognitive bias where a designer becomes stuck on a limited set of ideas, often influenced by prior knowledge, previous solutions, or dominant trends," explains design psychology expert Rachel A. Wood. More here. [^3]: Cover image courtesy: The Double Diamond from the Design Council UK [^4]: Design Sprint image: Courtesy Wikipedia.

Through the vibe-coding looking glass

Mon, 22 Dec 2025 00:00:00 GMT

Disclaimer: I had a shortlived career as a front end dev (IE7 era) at TCS when I began my career post-engineering in 2010, so I am familiar with the basics of web development. Hence vibe-coding on web may be slightly easier for me to grok then someone non-technical who is trying it out.

In October, when I started off my break, I wanted to explore vibe coding but the choices are overwhelming. Up till then, my exposure to LLMs had been to use ChatGPT to edit blog posts and using Midjourney for creating assets for Meta Ads and VC pitch decks. Attending Razorpay’s Design x AI in November helped me understand the realities of vibe coding and prompting but I needed an extra push.

That push came in the form of a relative asking me to review their 'Vietnam Travel Itinerary'. They had shared their 'Itinerary as a huge wall of text pasted on Whatsapp. I could figure out a few obvious issues with it but I decided to see if AI can help me review and visualize the issues instead. I felt this would help me communicate the issues easier with my relative.

Planning holidays and building itineraries is a hobby of mine, so I had tried ChatGPT earlier to help with trip planning but I had found it lacking. It was great at generating rough to-dos for your trip like places to visit, etc which I believe it has adequate training data on and to be fair, it’s great for a normie. However, it fails miserably in many places like recommending good stays and other kinds of specialized interests and I've also observed that it tends to think about planning in terms of a western or american perspective.

So I started asking ChatGPT to visualize the itinerary on maps and when it created an html artifact, I asked it to iterated on the design and visuals. But there was a lot of back and forth to get something done and often subsequent generations rolled back changes I had made. Below are couple of variations of my iterations, (left) from when I started to (right) when I decided to get it to make it swiss-inspired.

I hit chatGPT's session limit and decided to move it to Claude. That's when it got easier. Claude's execution of my requests were better. You could see an invisible multiplier in place such that a 1x simple prompt gave a 10x output.

That piqued my curiousity, I decided to see how far I could go.

I first asked Claude what it would take to "productivize this" and it gave me a very detailed product roadmap of everything possible including the kitchen sink. It was overwhelming, but I made me learn that asking Claude for a plan is a good way to source ideas but better to work through the designs in the traditional way of implementation (prototype > iterate, repeat)

It took me about 40 iterations[^1] to get to a state I was comfortable sharing with friends to get feedback. Claude walked me through the steps of setting up Claude API key and hosting the app on Netlify, something I've never done before. You can check out the project at Traviti.

Fun fact:

When I moved the html to Claude, it removed the 'Made by ChatGPT' label in the markup. Jealousy?
Claude struggled a lot to add it's own logo into the markup and I had to write the markup in the end.

This project gave me sort of confidence to build further. The itinerary generator was not what I would have wanted to build, but Budgie was. The time to build Budgie was faster. I now had Claude Pro subscription and quickly hit the weekly limit and had to stop so the v1 of Budgie took a week longer than expected to ship. Update: I shipped an updated version of Budgie over the Christmas holidays.

This was before Claude's release of Skills and I tried out using Projects for this. There was no Figma involved, just prompting and reading through CSS classes. There were some parts that I had to step into debug but largely this was coded by Claude.

Towards the end of this project, I moved to Claude Code on web and the experience dramatically improved again. Having Claude as a partner to pair with and write to the same repo was amazing QoL improvement.

After Budgie, I felt it was time to stop procrastinating and start working on my portfolio (this site). It had been previously built on Eleventy via Glitch (RIP) but I wanted to test how easy would it be to re-write this. So for this project, I asked Claude Code to review and then rebuild the site in Astro and I also provided designs I made in Figma. Claude was easily able to render it and since then, I've taken to making Figma mockups to move the designs along.

Midway through this, I decided to try Claude code on desktop and found myself lost a couple of times, so I decided to move back to Claude code on web. (I do want to try Claude code on Desktop for a future project where I build from scratch.)

Since then, I've tried my hands at visualizing my book reading on P5js and tried to clean up an old D3js assignment from a college module.

Honestly, LLMs have been able to help me overcome the barriers I used to face with hobby side projects and I hope more people get empowered this way.

Helpful tips if you want to get started

Starting new chat is the new CTRL+S. I struggled a lot on regular chat conversation. Claude Code however generates a nice summary of the chat when you hit context limit.
Be ready to make a LOT of iteratons. Designing on Figma and providing images has been generally efficient to get the outcome you want.
Start with small projects; for me that means static web projects. Identify what it means for you.
I expect design hiring to have a vibe coding round in the near future. Being able to translate your designs to a real functioning prototype has never been easier and moreover it gives an insight into how the designer solves problems.
Setup a free Github account and connect Claude to it. This will help with your versioning and the ability to roll back any unexpected changes. I personally prefer Github desktop over terminal and if you are new, I suggest you try that.

[^1]: At times, some of Claude's prompts generated multiple iterations so iteration 40 was more like 10 prompts into the conversation.

Thoughts on Hiring, part 2

Sun, 07 Dec 2025 00:00:00 GMT

There are lot of opinions out there about hiring. Part 1 was written in 2020-21, when I was on interview panels for product design and product management. Whereas Part 2 consists of my reflections after being in the role of the hiring manager and co-designing Jiva's hiring process.

1. Your hiring process is a reflection of your culture

The design hiring process isn't standardised. These days you'll see a variety of rounds; visual portfolios, take-home assignments, whiteboarding sessions, etc. The mix you choose isn't random; it's a reflection of your organization's culture. You're designing a candidate's very first experience of how your team thinks and works.

Different rounds signal different things. Asking for visual designs in a portfolio implies that your product team drives the flows and you need someone with strong visual craft. Take-home assignments (and their subsequent presentation) reveal the candidate's communication skills, which can be especially useful if your team works in a traditional "siloed" setup. Collaborative whiteboarding sessions show you how it feels to partner with them day-to-day but usually your organization's designers work solo within their own teams.

None of these are inherently wrong. But if you are not mindful about your processes you end up unnecessarily making the candidate experience time consuming, anxiety-filled, and worse, you start evaluating candidates for the wrong set of attributes — a costly mistake that almost always leads to failure down the line.

2. Today’s design team needs to be multi-faceted

When I first started taking interviews (in 2015), my evaluation criteria naturally leaned toward a certain kind of product designer — usually someone whose strengths mirrored what I personally valued. That worked when every designer owned a single product end-to-end. But as the organization grew, this approach started breaking down. Designers now had to work together, share problem spaces, and complement one another's strengths rather than operate in isolation and we hadn't hired for that.

A better approach — and one I wish I had learnt earlier[^1] — is to step back and visualise your team's skillset as a whole. One simple way to do this is by mapping your organization's design competencies onto a rough spider chart or competency map[^2] and plotting each designer against it. It doesn’t need to be perfect; the point is to create a shared view of where your team is strong, where it’s weak, and if you’re overly dependent on the skills of a single person.

This kind of visualisation becomes even more valuable when you’re managing multiple teams or products. It gives you clarity on what gaps you’re trying to fill, instead of defaulting to hiring “more of the same.” For example, pairing a highly visual designer with a more analytical one can create a healthier balance, with each designer taking control of the tasks as per their skill sets.

In other words, what you need to realise is that you are not hiring an individual — you’re shaping the distribution of strengths and weaknesses across your entire design function.

3. There is no place for ego in the team

It’s called a design team for a reason. The product the user experiences should feel seamless, not like a patchwork of different personalities, preferences, or stylistic signatures. One of the biggest gaps in a skills-only evaluation is that it completely misses the collaboration layer of design: how someone shows up, how they listen, and how they work with others under pressure.

Your spider chart or competency map can show you strengths and weaknesses in craft, but it won't tell you whether a candidate can actually work well with the rest of your organization. That’s where cultural alignment matters. A designer who is stubborn, who refuses to take cross-functional feedback, or insists on “their way” will quickly become a bottleneck — no matter how talented they are.

Getting people who play well together is one of the most underrated aspects of building a high-performing design org. A difficult personality erodes trust, slows down execution, and adds unnecessary emotional weight on everyone else — a mess that you, as the design manager, will spend a lot of time and energy sorting out.

This is why running a “vibe check” through your existing team — designers, PMs, engineers — can be invaluable. These aren’t popularity tests; they’re ways to sense how someone collaborates in real, messy, day-to-day situations and to check how excited stakeholders are about working with the candidate.

The goal isn’t to hire the best individual — it’s to hire the person who will make the team stronger.

Cover image: Akshay, Hetang and Riya working on a whiteboard at Practo, 4 April 2017

[^1]: Derived learning from faculty from Ownpath Manager training in Q1 2020 where we interacted with Kristin Skinner, Alysha Naples, and Meredith Black. [^2]: Jason Mesut's Shaping Design series of posts is full of useful toolkits and design management frameworks.

What is a product designer?

Wed, 01 Jan 2025 00:00:00 GMT

A decade ago, the 'product designer' title was being used to refer to designers (and still is) working on physical products. The adoption of using it for software designers got a shot in the arm when Facebook adopted it for their designers. Until then UI/UX was the term of choice for folks in the industry and used to indicate a specific job that the designer performed in the team. This was indicative of the shift from the delivery teams working with client requirements (enterprise first) to product teams (rapidly iterating consumer tech) which had to learn and uncover what was the best product they could build. Due to the scarcity of product designers in the space, companies started acquiring design agencies around the world[^1].

The 'product designer' now had to start looking at what they are designing as a product and not be restricted by your traditional mindset of UI and UX responsibilities. This would mean that they would need to learn about business, uncover user insights, use data analytic tools, have technical understanding, etc to design their product. These aren't skills that come naturally to designers and therein lay the problem. Not every designer wanted to be a “product designer” but it was an aspirational job for designers given the pay packages were miles ahead of what designers were paid in other industries. More and more companies started adopting the term of ‘product designer’ to follow industry trends and attract talent.

But even then there were few orgs which took design seriously.

[^2]

Even today, most orgs don’t really provide a space for designers to thrive in the product space and even today, there are probably a handful of product designers and product orgs in the world, the rest is mostly good PR.

And what are the aspects of a product designer that sets them apart from other designers?

Quality

The primary aspect the product designer optimises for is quality of delivery. Quality being subjective makes it hard for the different disciplines to align over what this means. For me, it means that the product designer needs to understand the constraints of business and development to be able to deliver the best outcome possible in the defined timeline. You may want to build that perfect animated transition, but let’s be real, that’s not really a user need most of the time. The product’s usage and success should be the thing driving you towards excelling as a designer.

Curiosity

Just like Alice, a product designer has to be inquisitive about their users and their behaviour and the systems they inhabit. The ‘product designer’ need to be comfortable looking at dashboards, analyzing events as well as drafting a research plan and talking to users. The best way to level up as a product designer is to learn from what you are building and putting out into the world. And this learning tends to compound as the years go by and helps you take decisions when faced with new design challenges.

Craft

The product designer is actually T-shaped despite a lot of folks thinking that they are generalists. So although the industry largely refers to the visual polish as 'craft', I don't feel its restricted to just that. You could be a 'product designer' excelling at copy writing, or a 'product designer' inclined towards the code side. A good team is made of many such designers who can learn from each other. If every designer you hire (or in your team) has a similar skill set to you then there would be limited direction for you to grow in. Some teams out there have chosen to double down on this kind of team building but to me that's building a design specialist team.[^3]

Agency

This is a quality which is rare to find. I feel this is because most designers tend to be introverts and love to be comfortable in their “space”. It’s easy to spend time in the world making pixel perfection your entire personality, it’s not easy to go out on a limb and argue for a decision to be made. Unfortunately, agency is what helps you level up the ranks. Agency is what gets you a seat at the table. Another hurdle towards product designers developing agency is that they need to be part of good teams run by design leaders who support and sponsor you and those are really scarce in supply.

So where do we go from here?

I see that we need to address this at a system level, today the ‘product design’ comes with a better salary and so for designers to get better pay it’s better to call themselves Product Designers. So things can’t change until the hiring parties don’t get better at their jobs.
No one designer is the same as the other. Organisations should be cognizant that there are no such thing as generalists and design their career rubrics in a way to suit the different kinds of designers on their team. This helps each designer to grow in their own way within the org.
Job descriptions could be honest up front of the kind of designer that they are looking for rather than getting ChatGPT to write it. There is no point lying about this, infact it just takes you lot longer to find someone.

[^1]: John Maeda's Design in Tech report 2015, Slide 4 https://www.slideshare.net/slideshow/design-in-tech-report-2015-45858974/45858974

[^2]: Silicon Valley "didn't think a designer could build a company" says Airbnb co-founder Brian Chesky https://www.dezeen.com/2014/01/28/silicon-valley-didnt-think-a-designer-could-build-a-company-interview-airbnb-co-founder-brian-chesky/

[^3]: Pablo Stanley, Collection of Random Comics https://thedesignteam.io/collection-of-random-comics-d66f32ee9c52

This post was my response to Sidu's Hiring Product Managers and John Allspaw's On being a Senior Engineer.

Attribution: Cover image courtesy 'The Process of Design Squiggle' by Damien Newman, thedesignsquiggle.com

Evaluating that Solo Designer job

Mon, 12 Feb 2024 00:00:00 GMT

You often see people stating that they are joining as a solo designer in a Startup and want advice. Them being the solo designer shouldn’t directly impact their effectiveness.

Here’s what I feel matters the most towards their success:

1. What is your role?

Knowing why they opened the designer role is important before you take that job. I recommend that you ask the hiring manager this question during your interview rounds and also ask to speak to the critical members in the team you will be joining. I take it that most Founders open a position because they got some feedback from customers or because their investor told them to. They may not be ready to invest in what can make a designer effective in their role.

2. Fitting into the team:

The team would need to adapt to having an in-house designer working with them. The team members would need to understand what the role of the designer is and how they could work with them. They would need to take time to adapt their workflows or create new inclusive processes. All this is hard to do and the designer(especially a junior one) wouldn’t do very well without a sponsor.

3. You need a sponsor.

One of my key learnings has been to choose to work with someone who will be your advocate in the organization. It's the single most important thing to look for during the interview process. The best teams I've observed had CEOs being the design sponsor and their products tend to win at least in terms of product quality (a product's success is more than it's quality, but that's another post) Don't believe me? Well in Rams, Dieter Rams states "If you don't have someone who stands behind you, then you can forget it." And cites it as a reason for leaving Braun.

Of course, not every Startup out there succeeds and there's no guarantee that the team you join will survive but its always good to make sure that you enjoy the team you spend there and learn how to become a better designer.

If you are looking for advice on what you can do as a solo designer to succeed, this post I wrote after my first year as a designer may be useful.

How far we've come: The last decade of design tools

Mon, 15 Jan 2024 00:00:00 GMT

Last night, I was thinking about how much the interface design and prototyping landscape has changed in the last decade. I started using Sketch and Marvelapp in 2014 when the predominant tools were Adobe Illustrator/Photoshop/Fireworks for UI, Balsamiq for low fidelity, Axure, Omnigraffle and Keynote for clickable prototypes. Some of these still exist today. While others like Antetype, Invision are no more.

I was taught to design on Photoshop at my first job. Even though, modern app stores had released three years earlier, websites was what we were designing back then. The Photoshop art boards we designed, would be ‘sliced’ and used in our HTML/CSS mockups. 'Redlining' was common practice for dev handovers. For personal projects and at hackathons, new age CSS/JS libraries like Twitter Bootstrap started being used. The designs I made back then are horrible and still exist in un-recoverable file formats (Okay, I actually found a photo of one design). Back then, I was a developer with an engineering degree working in a MNC IT company so I can’t blame myself for it.

When I was at Design school, using Adobe Illustrator for its vector capabilities became common place. We worked on information graphics and photoshop just didn't cut it for our workflow. It was largely a skill problem since we had no teachers for our tools, whatever we did was with knowledge from the internet and our peers. Outside in the world, the industry was using tools like Axure, Omnigraffle and Keynote and Teehan+Lax had legendary status in their community for their annual release of their iOS kits.

By the time we graduated, there had been changes in this ecosystem. Sketch started picking up market share, smart phone penetration was trending up and collaboration became an important buzzword. It was 2014.

By the time, I started my internship, Material Design had launched and I upgraded from my ancient Sony Viao to a MacBook Air (on EMI). We adopted Sketch and Marvelapp at my workplace.

Back then, Sketch files were saved in Google Drive Shared Drives for archival and access across the team. You still needed a license to access proprietary content so we still needed to redline screens and share exports in folders. This lead to tools like Zeplin, Invision and Marvelapp coming in to fill this gap. The next year, Facebook released Origami built on top of Quartz Composer followed by Framer 1.0 in the next year. That was the start of making prototypes multi-dimensional and letting users “interact” with UI elements and granting access to device hardware sensors like camera. There were people that I knew making really cool stuff with this.

Next, Figma and Abstract started up trying to solve the file organization and collaboration problem in their own way; Figma’s USP was that it was browser based and hence could be used by non-mac users so great for budding designers who couldn’t afford a Mac. I didn't use Figma until Jan 2022.

Abstract targeted the existing Sketch user base and tried to introduce branching to the designer audience (albeit unsuccessfully?). Framer X built some hype but it didn’t catch on. I had beta access and building out a component system on Framer X(React) needed Dev support which most design teams didn’t have the luxury of. This (circa 2019) is when you started noticing design teams around the world having UX Engineers in their rosters. Design systems evolved out of style guides with the help of UX engineering and now we take design sytems to have both a design and code aspect to them along with voice, tone, illustrations, etc.

Then came the no-code/low-code revolution which simplified the ease of creation further and tools like Glideapps, Bubble and Landbot now make it easy for you to prototype and share ideas. And that brings us to 2024, where we are seeing the rise of AI assisted design and dev tools getting focus. These aren’t there yet but I wish with this we can sunset that beaten to death question of “Should designers code?”

An Insider's perspective on Design in Tech 2024

Mon, 01 Jan 2024 00:00:00 GMT

After the Great Layoffs, I've been seeing too many people declaring the death of design leadership and with the rise of AI, the death of the digital design industry as well. but I find that it's a poorly informed take and no offence, but in my opinion, written by outsiders or written about a specific industry/region/designer. In fact, there are a lot of highly priced leadership training courses out there these days.

Over my career of 10 odd years, I’ve had the honour of being an observer in the product design industry of 2 countries; India and Indonesia. My perspective comes from my vantage point of living in the Silicon Valley of India and professionally, from being part of the growth stage of the well funded startups.

For this article(rant?), I will use Startups vs Big Tech for sake of categorisation. Big tech would have the minimum expectation of being a listed company operating across more than 1 geographical region. Meta and the other MAANG companies would fall into big tech but do remember that they are the new entrants in a space already filled by CISCO, Intuit, Adobe.

Post the dot-com bust, we saw the slow rise of today’s modern digital startups. First in the Silicon Valley and then in the rest of the world. This was mainly fuelled by the VC funding and still is. This lead us to look up to the Silicon Valley companies and the folks there as thought leaders for design. And rightly so since they were working on products we admired and used half a world away. That scale and magnitude is definitely something to be proud of. They encountered and solved problems at scale, establishing standards, registering patents and forming user behaviours that we take for granted today

But in our part of the world, even today, digital product design is still attempting to break out of its UI and UX tags. When I started out in 2014, UI/UX was the predominant way of describing designers in big tech, and even startups. Of course there were exceptions, but I will ignore them as outliers. The startup I worked at back then, was one of the first in India to adopt Facebook's popular convention to start using the term 'Product Designer'. Back then, the Indian digital design industry was so small. You were separated by 1-2 degrees from everyone and arguably, it's still that small. The VC funding, however, gave rise to a notion that tech startups are a lucrative career compared to the dominant IT/ITES industry. This led to a gold rush fuelled by opportunistic bootcamps and certification courses, most of which churned out low skill designers. However, unlike the West, few companies thrived and hardly any have scaled and now we have a supply-demand problem at hand.

This leads us to where we are today:

Local companies are not getting 'Big' enough or if they are, once they get listed, they need to justify costs and respond to the market. It's quite easy for decision makers to take that call and cut a few roles to keep costs in check. Easier than getting out of your software license contracts to cut costs. Also much easier to do this when others in the industry are also doing layoffs. Smaller companies mean there are fewer senior roles to be filled especially when most teams out there are feature factories who know what to build next.
In my experience, Design leaders in startups have always been expected to play a dual role of designer + manager. In fact the designer aspect is valued a lot more while the manager title is granted to keep designers happy. That said, Most companies do not know what to do with the design leaders that they hire. So often, what you encounter is the Design Leader who is a figurehead to appease the junior designers with almost 0 influence on business outcomes or worst case, to be head of design of a design team of 1. This explains the short tenures because those roles are just not fulfilling.
This may anger a few, but in the current state of the industry, design progression ladders don’t need an IC track beyond the level of a senior designer of 5-6 years of experience. If you are not a Meta/Google, I don’t expect there to be scope or complexity that needs Staff Designers. So where have these senior designers been going? Well some of them move into “Manager” roles without the skills to operate in them while others tend to move out of the country to join companies which may have grown to a larger size or worst case at least they get to experience a new culture.
The skills you need as a manager are different from the ones you polished as an IC designer. Being good at Figma can only take you so far, if you don’t have an affinity for bureaucracy, then being a manager is a bad fit. On the other extreme are the managers and heads of design, usually from a background in older big tech companies, who were at positions where their job was to pontificate about design and innovation. These folk tend to be disconnected from the day-to-day work and that’s bad for the team as well. Both of these are highly replaceable roles.
And finally, we have not moved away from the worker productivity categorisation of industrialisation. Bell curves are common, business wants to keep control and budgets are paramount. I would like to argue that Design never got a seat at the table. The "Design Thinking" hype that got thrown around by IBM, McKinsey, IDEO was for their own PR and has run its due course. Everyone likes an optimistic story but rarely would you find actual organization leaders(CXOs) believing in the value that Design brings to the business and actually investing into Design. That is as true today, as it was a decade ago and hence good fulfilling design jobs are few and far between.

This does not paint a very rosy picture of today's design industry but after all these years, this is my honest take on the state of affairs. Perhaps we've been swayed by all the positive marketing around design, perhaps we've believed that design in tech can save the world, but in reality, designers find themselves in a dystopia that they don't want to acknowledge. The old folks of the industry who have survived, will continue to do so but if you are a beginner, if you want to stick to design in tech, I recommend that you choose a discipline like engineering or product instead and leave your empathy at the door.

Thoughts on Hiring

Thu, 19 Aug 2021 00:00:00 GMT

"For every open job on your team, you need to spend one hour a day on recruiting-related activities. Cap that investment at 50% of your time."

–– Rands

I strongly believe that hiring is a critical focus area for a design leader. I've been part of hiring panels since 2015. I've seen companies usually do not focus on hiring flows leading them to have a bad experience for interviewing candidates.

I gave a short talk about hiring designers at a friend's startup in 2018 which could be drilled down into the following key points.

Write good job descriptions: The industry is filled with nonsense JDs ~written~ copy-pasted by HRs. If you need to stand out, you need to write a good JD. Hire a design consultant to help you out with this if you are hiring the first designer for your startup.
Don't let a portfolio be a barrier for applying: For entry level roles, I feel a portfolio acts like your resume but when you start hiring for senior designer roles you may want to broaden the application criteria. Most designers I know do not have an updated portfolio and this prevents them from applying to your startup if they are interested.
Customize application form to allow folks to upload a digital document: The tool you use to run your hiring needs to be flexible to cater to your design hiring needs. At Gojek, we used Lever and for the longest time we did not have a way for designer applicants to upload a pdf portfolio. Binoy and I sat and figured out how to add it to the application form, however for internal referrals we were not able to enable it as Lever doesnt let you customize the form.
Keep the face-to-face rounds short: In the interest of everyone's time, its best if you can earmark a particular day of the week for interviews and schedule all the rounds on that day for candidates. For this to work, your screening rounds need to be well designed so as to not overload your panelists.
Scaling the process: If you have a lot of reqs to fill, you will need to get others to take part in the interview process. Playbooks and evaluation templates help scale the process while maintaining quality.

Cover image: Taken at the end of the Bandung edition of Gojek Desain Keliling, Gojek's attempt to recruit designers in a sort of reality contest where winners would get golden tickets and a chance to be a part of the Gojek design team.

Beyond building processes at GoMerchant Design Team

Thu, 19 Aug 2021 00:00:00 GMT

A considerable amount of time in 'Year 1' of being a manager has been about setting up artifacts and processes. I was lucky to be part of an organization that had a documentation culture in its DNA. This was partly because we had Program Managers embedded within each team. This meant that Jira, Confluence and Asana were setup and maintained religiously, with weekly feature spec reviews [FSR] and ProdTech meetings to keep these upto date.

Setting up Documentation spaces

I find design documentation to be a critical part of the design process. I recommend every designer takes the time to document the project because apart from being a design artifact, that serves as a single point of truth, it also helps them when they have to write their performance reviews, promotion proposals and build their portfolio.

I do not like Google Docs for documentation. Documentation spaces need to be a searchable wiki and ironically Google Docs is poor at providing this. At Practo, we already had Atlassian's Confluence setup when I joined, and at Gojek, Maji setup our Confluence spaces in 2019 and then the two of us started structuring and documenting our knowledge about the product and its processes. I created a design documentation template based on the product feature spec template and advocated for it.

As for project management, the org moved to using Asana. Adding them here felt forced and an unnecessary addition to our workload. However as our product roadmap was moved into Asana, I devised a process to make design tasks a visible part of the product development process by adding them as subtasks and duplicating them to our design boards for effective tracking. Post every prioritization meeting, I added tasks into the todo list and tagged designers so that they were aware of what's coming up.

However, we faced a problem with adoption of these processes. We lacked a program manager dedicated to design and not all designers in the team were able to keep their boards updated. We were able to setup a biweekly cadence with the program management VP, Gifika, to discuss our problems and understand how we can get better at solving them. And what we learned is two things.

Add more meetings in the calendar
Be a bad cop

More meetings in the calendar

When your calendar is already full of meetings, you feel like staying away from setting up any more that will take away whatever little 'time for focus work' that is left in it. But given our problem, this seemed to be the most effective way to get things working. Our team was a 3 level hierarchy so each lead now had to setup two additional cadences into their calendar. One was a common stream leads cadence where each stream lead would come prepared to the biweekly meeting with a progress update (which would be posted biweekly to the Asana board) Maji worked on a template for this.

The other meeting was with their stream where each of their reports could come with a similarly formatted update. This meeting helped stream leads prepare them for the stream leads meeting. You can also make these meetings async if everyone is diligent. The updates were a small part of the biweekly leads meeting.

Be a Bad Cop

Not all designers like following process. They may see it as additional work with low ROI or they may just not have enough time. You should take the time to communicate the problems that the process is going to solve and ask them for feedback on the process. Make it feel like they co-own the process. But if this fails, then you should be okay with being "bad cop". This would mean that you would need to set Slack reminders, add calendar invites and send DMs if everything fails. This is the way.

Team rituals and culture of the GoMerchant Design Team

Thu, 19 Aug 2021 00:00:00 GMT

As the GoMerchant team grew, processes and rituals became very important.

1. Design Critiques

Design Critiques were the first one we instituted. This was a weekly design and research only session where designers could present their work to other designers. These would be weekly and designers were encouraged to show work in progress. To setup this session as a safe space, leaders were expected to be vulnerable and lead by showing their own work in progress.

2. Design Review

With a need to showcase our work and drive alignment with non-design stakeholders, we setup a Design Review. The format of the design review was formal compared to our informal design critique. We invited non-design stakeholders to the review so that the feedback we collect could flow back into the design process. This was done weekly if required but usually as per our product development cycle it was bi-weekly.

3. Design Standup (for lack of a better term)

I used to be the only designer on my team based in India, but until the lockdown I did not think about instituting any daily standups. I used to frequently travel to Indonesia and everyone else was based in the same office. I felt that was enough. But when the pandemic hit and the designers started being isolated in their houses, Maji and I decided to setup a daily cooler talk. We called it Design Standup but we didn't want it to be a 'standup'. We encouraged folks to talk about their personal life, what they were going through and what they were doing. We played games, drew murals together on digital whiteboards and went down internet rabbit holes. Attendance was never compulsory, you could join in if you felt like it. We always posted the link and created a thread of what we discussed on our channel so that if you missed out, you could still follow what was discussed. This ritual couldn't have been achieved without the team members especially Maji, Lauditta and Aryo driving the conversations.

I wonder if this is replicable or was I lucky to have this wonderful team…