Seven years.

In the hyper-speed realm of fintech, particularly at a company as relentlessly innovative as Razorpay, that’s arguably a couple of dog years for a career. Looking back, these seven years felt like being strapped to a (mostly controlled, thankfully!) rocket, where the view — and my role — seemed to expand at a rather exhilarating clip.

This isn’t a boastful recounting of milestones, but rather an attempt to decode that “Razor-fast” acceleration — the kind of shorthand for levelling up that one develops in the trenches. Think of it less as a definitive map and more as a collection of well-used navigation tools and noteworthy landmarks observed from the cockpit.

We will do it in 4 bits — Business, Skills, Peers and Growth.

The “Business” of it.

Early on, my focus was, quite naturally, on the craft itself. But a significant turning point was realizing the profound impact of understanding and defining the “scope, scope, and scope” of the problem.

Build MLPs. MVPs are too basic.

A core realization was the difference between a Minimum Viable Product (MVP) and a Minimum Lovable Product (MLP) . The second pyramid above, the MVP, often stops at “Functional” — if it works, it is good enough to launch. But as designers, our aspiration must be the third pyramid, the MLP. Compromise on scope, but ensure that the scope being built, has all the layers of product building baked in.

Sure, being functional is the non-negotiable base, but the apex of delight, offering unexpected joy, is what transforms users into advocates. This creates the difference between a tool that’s merely tolerated and an experience that’s truly valued.

“Skills” beyond the obvious

Naturally, sharpening core design skills was a constant. Yet, the real acceleration came from embracing a multifaceted approach to skill enhancement.

Designing for users? Not good enough. Design with them

This principle became a guiding light. Engaging directly with users, observing their workflows, and understanding their context transformed my design process from assumption-led to insight-driven.

Recently while working on introducing a new top nav, here is how we iterated through the versions. Running each one through multiple users and ending up with v3, which is what is live now.

1. In v1, the users were unsure of whether to navigate between top nav items first and then through side nav ones or vice versa?
2. v2 solved that problem, but created another. Top nav was taking all the attention away from everything else on the dashboard.
3. v3 was the middle-ground that worked for the business and the users.

Stories sell. Powerpoints just… point.

While proficiency in design tools (the “hard skills”) is essential, I found that “soft skills” were the catalysts for impact.

The ability to cater to the listener , to understand their perspective, and to articulate design decisions became paramount. I learned that stories sell far more effectively than a mere recitation of features.

A well-told story about how a redesigned checkout flow reduces friction can be far more persuasive than a list of cool UI changes that we have introduced.

Steal like an artist
- Austin Kleon

Thin line. Steal, not copy!

Take the entire universe of QuickCommerce, for example. The product listing pages look eerily similar for a majority of them. Does it mean that one of them copied the other?

Well, it is much more likely that the setup just works.
No reason to break your heads coming up with a new pattern when it is a solved one. Sometimes, being different for the most basic patterns might actually be more detrimental.

The important difference though, is to study, and not just skim; understand the underlying principles; and then, transform and integrate those learnings into a novel solution.

When we were building an in-house conversation AI Assistant, RAY, we did learn and studied all other similar interfaces. Ended up with the basic elements that made an assistant, feel like one — prompts to start and a conversational feel to the interface. Yet, it was distinct from all the other interfaces, because it had elements that made it Razorpay’s — the colours, the logo, the way that we shocased the prompts.

We learnt from everyone, and made something novel.

Zoom. Sometimes in, other times out

One moment I might be deep in the details of an icon for “a payment method” , the next I’d be zooming out to consider the entire merchant onboarding journey and its strategic impact. This constant shift in altitude is critical to ensure both pixel-perfection and strategic alignment.

“Ownership”: From Observer to Instigator

A pivotal shift occurred when I moved from being a contributor to an owner. There won’t be a title change, but this is just about a mindset transformation.

Found a problem? It’s yours now.

Instead of just identifying an issue, for me, the impetus became to communicate it — Slack it, explore solutions — Ask how we can solve it, and champion its inclusion in the roadmap.

In this new AI world though, that simply doesn’t cut it. The expectations have changed. The tools are there for all of us now to build end-to-end experiences. Or at the very least, create life-like prototypes that can help garner life-like insights.

Being an “Obnoxious Owner” is perhaps my best personality trait.

God’s honest truth? A designer doesn’t get invited to every meeting. Or always considered critical in every conversation. Quite a few of them might benefit from having us there or we might benefit from being.

Ask for it. Stalk calendars. Find conversations, and ask to be added. Walk into open meetings. Do not wait for a seat at the table. The table is long. Just grab a chair.

Keep rocking the boat. Gently at first. Vigourously, as needed.

This isn’t about contrarianism, but about fostering deeper thinking through inquiry: asking “Why?”, exploring “What if…?”, proposing alternatives, and rigorously considering “What can go wrong?” when discussing a new feature or a change to an existing flow.

We play the role of checkers.
We play the role of gardeners of experience.
Our job description is just the starting point.

Everyone is better than us at something
- Guy Kawasaki

Each function offered a unique “goggle” which they wear while they operate. Every single one of my peers had something fresh to offer. Here is how each of their perspectives look like.

Decoding “Growth”

We are at the end-game now.
And if you were expecting a path to climb the corporate ladder as a designer, I hope I have disappointed you to no ends. However, I do have a small tidbit on growth though.

When you really grow, you are the first person to know it

There’s an internal shift that precedes external validation. Here’s the surprisingly useful metric.

Do you hate what you did a year ago?

Because if you do not, you might not be growing fast enough. The faster you start hating what you did, perhaps the faster you are growing.

My largest struggle through the last 7 years has been the confidence to build a portfolio. Every 6 months that I look back at my work, I feel like I would reject myself if I did this today.

Here’s how my work across the years has looked like. Every one of them look so so underwhelming today.

Fail fast. Fix faster. Tell everyone.

One last sermon. I promise.
I think we do hear the first statement often enough. Failing fast is great right? However, what is the point if we don’t fix faster than we fail?

Most important though, is to not be afraid of failing. And hence, making all stakeholders aware about failure. Sure, it should be accompanied by a plan to fix. But hiding failures is perhaps the hardest friction point in our careers as designers.

Onward & upward…

So, after seven years in this design dojo, the big reveal is… there’s no final boss! Growth, it turns out, isn’t a one-time hyperspeed jump. It’s the daily hustle of owning your slice of the universe, passionately crafting those MLPs (because “viable” is just table stakes, isn’t it?), and soaking up insights like a (very absorbent and design-conscious) sponge.

The canvas is always bigger than you think. The table, long enough.

Pushin’ Pixels & Progress: Evolving as a Product Designer was originally published in Razorpay.Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

A sneak peek into what makes the everyday life of designers at Razorpay easy

Razorpay, right now, is a 29-member team. For us, the process that we follow defines the tool stack that we need to have. The tools in themselves, are of meagre importance in comparison to the process that they are supposed to facilitate. A lot of times, great design happens simply on paper, or on a whiteboard.

To know more about our process, here are a couple of links you can actually refer to:

• A Twitter thread on our Design process
• A blog by Shashank Mehta on how Razorpay used Design as a differentiator

Tools and software come into play owing to the need to optimise on time and effort. And in spite of the fact that good tools have very little to do with good design in general, they do in one way or the other, define ways in which we follow the design process and execute solutions.

This article contains a high-level view of the toolkit that the designers at Razorpay use. A lot of times, we’ve seen that folks are unsure as to which tool to use for a particular task. The intent of this article here is to perhaps assist our fellow designers out there with picking up the best possible medium to carry out the task and maybe find opportunity areas to reduce time and effort spent via one of the means we’ve been using at Razorpay.

Communication & Planning

Before we get into the tools used strictly by the design team, I would want to touch upon the ones used by the entire organisation in general. These are used majorly for planning of work, long and short term, and for communication in general.

Slack

Every conversation is plugged in here. One of the core values of Razorpay is transparency, and in accordance with that, DMs are highly frowned upon. Right from an online standup to notifications of our mentions on social media, everything is piped into Slack and can be discussed and tracked there.

Almost every one of us in the team has 30+ channels joined, of which ~5 would be used actively on a day-to-day basis. The recent changes in Slack do help us quite a bit in that regard.

Gmail

Well, a no-brainer. Every organisation needs an email client, and what better than Gmail, yeah? The external communications happen here, in addition to serving as another means of internal communication, especially if it needs to be personal or sent to a larger audience.

Zoom

Online meetings are the norm with the work from home setups becoming commonplace. Razorpay however, had been using Zoom from even before for external communications, or for colleagues who need to join into meetings while working from home.

Google Calendar

Want to talk to someone? Need to have a discussion with a group. Well, first things first. You would need to block time on their calendar. The calendar is the source of truth that needs to be referred to for setting up any discussion.

JIRA

Widely known as a tool used mostly by engineers to track their tasks, here at Razorpay, designers are expected to plan their work for the next two weeks (sprint) on JIRA. This achieves two things:

1. The designers themselves know what they will be able to achieve by the end of their sprint.
2. Since the work to be done by designers and developers is one single platform, it becomes much easier for all the stakeholders to track the progress of the project being worked on.

Designers attempt to break down the larger tasks into smaller ones so that the prediction of timelines is easier and more transparent. We’re not saying that we all love JIRA, but at the end of the day, it does solve a number of problems in our organisation. Apart from that, we also have a running backlog for design to take care of. This helps in tracking issues easily and driving them to completion along with the tech team.

X to 10X

Razorpay follows an OKR structure. This particular tool serves as the one place where we document our yearly and quarterly goals and track their progress.

Brainstorming & Documentation

The very first step of every design project, the first step of the design process in general. This step in itself has multiple parts. We start documenting our thoughts about the project and the requirements for the product while brainstorming on multiple ideas and approaches in parallel.

Google Docs

The most widely used tool for writing documents — whether it is a Product Spec or a Design Spec, or any other document for that matter. Documenting using this medium makes it easier for us to comment on things and have discussions offline on the document itself, if necessary. Discovery of different documents is easy as well, all thanks to it being all on Google Drive.

Google Sheets

Any kind of data tables to be stored? Any numerical information to be processed? Well, what better than Sheets. This, in addition to Docs, is where all of our documents or research stay.

Notion

Notion, right now, is a tool that is used by people only if they really need to use it. However, a couple of the teams are using it on an experimental basis at this moment. RazorpayX team uses it for almost everything right now, starting from Employee onboarding documents to a record of feedback conversations with users.

Paper & Whiteboards

A lot of the brainstorming happens on paper. In terms of working on general approaches that we need to take with the product, the ideas are generally jotted down on paper. In case there are multiple of us working on a product, we brainstorm on whiteboards so that we could collaborate.

Figma

Of late, especially after the work from home norms came into play, we have started having a number of brainstorming sessions on Figma itself. With the most well-known feature being that of being able to collaborate online seamlessly, Figma makes giving life to ideas together online very easy.

User flows & Wireframes

Once the problem space is kind of understood, the next step is to work on user flows and define the directions that a user will take in the product. Of course, the step is paramount to remove any biases of ideas that might have already crept in, in addition to gaining a clearer visual image of the overall product. There are two tools that a majority of us use in this space — the choice is again a more personal one.

Whimsical

Whimsical was the first tool that the team discovered in this domain, and it became our beloved straight away. Whimsical is easy to use, makes creating flows seamless and look so so simple. Additionally, unlike a majority of the competition, the flows would look effortlessly neat. Whimsical does not really let users play around a lot with custom features, but that is more of a pro than a con. Concentrate on the important things, yo. The look and feel of the flow is great by default. An unexpected plus was perhaps the collaboration aspect and how easy it was to simply leave comments on specific aspects of the flow.

Whimsical provides a very clean wire-framing means as well. Especially for those of us who like to create low-fidelity mocks digitally before painting the screens with the visual brush, this tool has been a blessing. The wires here are low effort and do away with the age-old problems of legibility when created on paper.

Miro

Another tool that we have started exploring in recent times is Miro. It has a lot of customisable features and templates to quickly onboard users. If you like to play around with your flows and the flow board itself functions as a low-key wireframe for you (trust me, it works that way for a couple of us at the org), Miro might be able to provide you with a little more playing field than anything else in the market.

Interface & Design system

This is where a majority of the design would have already been done, and the time has come to bring ideas, sketches and wireframes to life. There are multiple tools that we use in this phase, each with their own merits. The major distinction in terms of tools for product designers and visual communication designers is in this phase. While a majority of the product designers spend a lot of their time on Figma, our visual designers have a soft spot for the Adobe suite.

Figma

Figma has grown over time as a tool that has surpassed formerly set standards for UI creation tools. It was sometime in the last year when we decided that we needed to make the move to Figma from its closest competitor, Sketch. The migration was seamless and since then, we feel that we have reaped the rewards. Figma is a web-based tool that keeps everything synced, thanks to the Cloud. Apart from that too though, there are a few other reasons why Figma beats everything out there in the market.

• Online collaboration
  Figma allows users to share the files and collaborate in real-time. One of the major major upgrades over any desktop tool.
• Seamless Prototyping
  We will talk more about this in the next step, but this also allowed us to do away with Invision. With Smart Animate, this became more powerful than ever.
• Easy delivery
  We no longer needed another tool to deliver screens to the front end. Figma makes that seamless with all the required information available in the read-only mode. You do not have to pay a dime for the developers who only need to read the Figma files.
• Plugins
  This was one of the things that were holding us back from making the move from Sketch for quite a while. But just in a matter of months, Figma has been able to get numerous plugins via opening up the platform for third-party developers.

We have also built up the design end of our design system on Figma. With searchable components, auto-layout, shareable styles and easy overrides whenever necessary, Figma proved to be more than just a tool for the design system. It is an overall environment that provides the best possible means for the creation, maintenance and documentation of a design system.

The Adobe Suite

For the creation of user interfaces, Figma beats everything. However, depending on specific needs, and this is mostly in the direction of visual design, we also use a couple of tools from the Adobe suite.

At Razorpay, a vast majority of the illustrations are vector ones and hence the widespread usage of Adobe Illustrator. The same tool is generally used for the creation of icons as well.

However, once in a while, we need to create images and edit them as well. That is where Photoshop excels, and hence the need to use that as well, although sparingly.

Prototyping

Static screens can only talk so much about how the user flow will be. In order to make the entire product breathe, prototyping becomes paramount. This step not just makes it easier to envision the journey of the user, but if built extensively with all edge cases, a number of times, it also proves to be the one point of reference for the developers. There are multiple tools that we use in this phase as well.

Figma

Figma is the jack of all trades when it comes to building UI. We create the screens on Figma and then prototype it here as well. With the entry of Smart Animate, it also allows for the creation of sleek micro animations.

Principle

For more control with the micro animations, and to be able to achieve finesse, we sometimes need a little more sophisticated and a tool more concentrated on prototyping. That is where Principle comes in. Again, it works very well for UI elements and to express transitions within the interface.

After Effects

Need to edit a video? Or create complicated transitions? Here is where After Effects comes into play for us. Not used very frequently, but very few tools, if any, provide the level of customisations in terms of transitions that AE does.

Delivery

Figma

Figma has generally resolved all of the delivery issues for once. But with Figma prototype and the source file being easily shareable, it becomes all too easy in terms of delivery. Designers have a walkthrough session with the stakeholders and create a final delivery page on the Figma file. The developers are expected to interact with this particular page as all other pages contain iterations tried out by the designer.

Analysis

For Razorpay Design, the process does not end at design and implementation. Analysis of the impact plays a huge role. Designers are expected to go into the depth of how the users are behaving and interacting with the platform. Before the implementation of the design, designers are expected to specify the behavioural metrics that need to be tracked. To track metrics, product or behavioural, there are multiple tools that are brought into use.

Looker

All of our funnels and product data is shown up on Looker. Looker makes it easy to create dashboards on a need basis and has multiple levels of access depending on the amount of customisation a particular user might need to do on the platform.

Google Analytics

For anything behavioural, Google Analytics has been our go-to place for quite some time now. The whole idea here is to get a holistic numerical view of how the users have been behaving on our platform. Data points us towards points where improvement is paramount and that is where we go deeper, which brings us to our next tool.

Hotjar

Just numerical data can provide incomplete knowledge at the very best, and misplaced understanding of behaviour at the worst. That is exactly where a tool like Hotjar comes in. Hotjar records sessions of users, at least that is what we mostly use the tool for. Apart from that, Hotjar has also assisted us with heatmaps for specific pages and setting up forms (surveys, for example) as and when required.

In spite of all of the fancy tools that we use, nothing beats having a conversation with a user and a piece of paper to put down ideas on, to come up with solutions to the user problems. Razorpay has always provided designers with the flexibility to choose a tool that best suits their needs, and that is why we have been able to move seamlessly between tools when we felt one was serving our purpose better than the other. To give a personal anecdote here, Kshipra Sharma and I were the only ones working on Figma for 6 months before we made a case for the entire team to move to the tool.

End of the day, a tool can bring out a manifestation of the designer’s solution to a problem. Hence, choose the one that best suits your needs at that particular moment. For us as an org, this set seems to work the best and lets us cover all possible grounds. At the same time, we have had running experiments with the likes of Loom (for making product explainer videos), Airtable (for planning, and as an advanced alternative to Sheets) and Dovetail (for making better sense of user research conversations). The set of tools being used can and do change with time and changing requirements, all in an earnest endeavour to be able to provide the best experience to users while automating processes internally and saving buckets of time wherever possible.

To know more about Razorpay Design, do follow us on Instagram and Twitter.

Designing at Razorpay — the tools was originally published in Razorpay.Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

A lot of individuals might be starting out in the industry during this time, and teams would have quite a few freshers joining you. I hope this article here can serve as a helping hand for all individuals and teams involved.

More than a year it has been since I joined Razorpay as a Product Designer. Straight out of a Design school, this has been an unprecedented and unfathomable experience. Spending 4 years as a design student, you would feel that you have enough in your armoury to face the impending challenges that await. Well, it was not to be. The motive of design schools is more around opening up our minds and enhancing our thought process but there is a whole basket of befores, afters and durings of the design, beyond that curriculum, that the industry demands.

Undoubtedly, we would be expecting things to change, the need for an adaptation, but can we actually prepare for it? From what I have learnt here, perhaps a bit of heads-up would have been helpful at the very least. It has been a learn as you go experience for me throughout. Standing in my position now, I think knowing a bit of what to expect can’t be a bad thing, after all, right? This article from hereon would be an attempt to articulate what I learnt in my first 12 months as a designer and what an individual joining the industry should ideally expect to start off with.

Real people and businesses will be impacted.

Coming straight out of college, it is pretty difficult to conceive how designs had an impact in the real world. Projects done in college are focused more around ideation and structuring, with a majority of them not seeing the light of day. Even when they do, they are not really at a scale where I, as a student, could see their impact on people or businesses. Things changed drastically the moment I joined Razorpay.

Once I did actually start designing and perhaps even before that, I had to come to terms with the thousands of users that my designs were going to impact. I worked on the First Time User Experience on the Razorpay dashboard. This was something that would define the flow of every business signing up with Razorpay. To realise that there were multiple thousands of businesses going through this flow every single day, seven days a week was perhaps kind of huge for me as a fresh designer straight out of college. The fact that this was the first touchpoint of the businesses with Razorpay, and this experience would set the first impression of Razorpay, put pressure on the quality of the product and was an experience of a lifetime for a first-timer in design. This brings me to the next realisation — how design can change the behaviour of thousands of users.

A small change can lead to a major behavioural change by the user.

It is pretty easy for a designer, straight out of college, to not appreciate the impact of small changes. There are times when minor design changes are brought into existence without really considering the possible impact. It is not very straightforward to understand how just a minor change in the design, might be a small tweak in a signup flow, or a change of text in the UI can change the fate and decide the success or failure of your products. A designer can actually influence major behavioural changes and define the actions being taken by the users. In the aforementioned onboarding for the dashboard, we wanted to increase the number of MTUs (Monthly Transacting Users) and hence pushed for usage of other products along with the payment gateway. A small CTA opening up the list of products and voila, the usage of the top 2 products increased by approximately 80%. To see such a huge impact through such a minute change, that too in real businesses was overwhelming and a huge eye-opener.

The output will be measured.

In the industry, design is not just about the process. A designer might be following their design process to the point but at the end of the day, the success of the product will be measured in terms of how it impacted broader organisation’s goals, mostly in numbers. The expectation out of the design is set from the very beginning, and after it goes live, numbers should move the way that they were expected to. Data, impact, numbers — these words are often heard as yardsticks to measure success, not just of design but the product as a whole. To elaborate, if the number of users signing up was expected to increase after a change in the signup flow, a fall in the number of signups would be an unacceptable outcome from the project. Even though subjectively, the changed design might look and feel good, but not meeting the numerical expectations is something that will undoubtedly pull it down. I was introduced to this wonderful article, If You Want to Be Creative, Don’t Be Data Driven, on the usage of data and how to maintain the balance between creativity and basing the design on data. At Razorpay, designers are expected to dive into data and analytics and make sense of it. We feel it makes sense for the designers to actually track if their designs are working they were expected to.

The problem statement should not be based on assumptions.

A number of times problems are assumed to exist. There is no research to actually support that there is a problem that needs to be solved. As such, it becomes a wild-goose chase. Even if it is someone who has been in the organisation or in the industry for years, for example, a fellow designer, a product manager or your manager for that matter, it is erroneous to assume that they know and have clarity on everything. For one, a problem statement built on top of assumptions is pretty flimsy and would fail to give the designer any real insights into what actually needs to be solved. Hence, it is always preferable that user needs are considered before actually landing on a problem statement. Back it up with data or with conversations with prospective users at the very least. Both from a business and product point of view, it is essential to know for sure the existence of a problem that needs to be solved.

Understand edge cases. Know the ones that need not be solved.

A user journey for your product is never really straightforward. The projects that are done in design school, more or less, consider ideal case scenarios and have the liberty to skip edge cases. In the real world, that is seldom the case. In every product that is designed, there are unexpected states which are bound to occur. While it is exciting to work on the primary design flows of the product, for the design of a product to be called complete, there is a need to handle a number of cases. Starting from empty states and error states to non-linear flows, product onboarding and auxiliary cases arising out of technical limitations and network calls, a good design would cover one and all scenarios. Referring to an intriguing article on the matter of Design Edge cases and where to find them, for a detailed understanding of possible eventualities that are generally missed out on during planning a project. These eventualities should be planned for, as they are bound to occur no matter what. At the same time, in terms of planning, it is important to understand which cases need to be considered and which ones can perhaps be ignored in favour of time. I have learnt, over the course of the year that as a thumb rule, three parameters define the necessity to solve a use case — likeliness of the occurrence of the event, impact on the users due to the case, and cross-team effort needed to solve the situation.

Cross-team collaboration decides the final success of the project.

In college, academic projects were more about individual inputs or coordination with designers working on the same project. Cross-team discussions with engineers, product managers, etc. was never a thing we were involved with in college. Collaboration within the team, from the get-go, is what is more than likely to define the performance and by extension, the success of the product. For starters, product and design need to be on the same page in terms of the need for the product and the use cases that need to be covered. Going further in, at every stage, constant conversation, critiquing and feedback is as essential as actually getting the work done. The healthier the inter-team discussions are, the better the final product that is built out.

Projects aren’t always fancy and seemingly large.

Most of my projects in college were semester-long and allowed spending a long span of time on every aspect of the process. Quite naturally, I was all too excited about how I would be working on huge products once I am into the industry and expected it to be all be about working on one project for a couple of months and handling everything in great detail. Guess my surprise when I actually realised that not every project is going to be a huge, fancy thing to be done. Is it a bad thing? Well, I think not. As I have already mentioned, a minor tweak can actually create a huge impact and move major numbers in the right direction. There will always be certain minor enhancements that will need to be done on existing products. These ensure that the product is usable, or sometimes might be new features being added on top of the existing base.

Learn from all. Everyone is better than you at something.

Every person has their own core set of abilities. In terms of design itself, I tried to learn the skills I lack from the person who possesses them best. Talking to all around me, and taking in their best abilities. A designer has to be a jack of all trades. And it is not just about core design skills. An organisation is a group of people from all facets — product, engineering, business. Interact, learn and teach. This would help both the designer and the organisation grow. Sometimes, the most groundbreaking knowledge is gained from the most unexpected of sources sitting across from us at the lunch table.

There is no fixed design process.

A majority of my academic knowledge is around design processes — which process to follow when, and what are the exact steps involved. Whilst there is always an ideal design process that every design team wants to follow, it is ever-changing and ever adaptive. There may be teams that are able to follow the process to the letter for all of their products, but in a majority of the organisations, it is not always possible or might not always make sense. There are constraints that define the process to be followed. For a large project, we would ideally want to follow every step to avoid any miss, while for smaller ones, it would perhaps make more sense to get the changes live and track the impact. It also depends on the stage of the project. To give you examples in terms of the products being developed in Razorpay — we follow detailed processes for mature products, such as our Checkout Form, while for a product in its MVP stage, like RazorpayX (a neo-banking platform being developed for businesses in India), we quickly iterated and came out with the first draft within a very short span of time. However, on a personal level too, experimentation with processes is something that I have constantly done over the year. It ensures that gaps in the existing process are plugged and made me adaptive to situations. As a designer, it was important for me to understand the underlying reasons for every next step needed and thereby take a call on what exactly is to be followed when.

Get your hands dirty. Iterate.

No matter how streamlined the design process of the team is, I felt it is always important to keep practising. Listening to John Lennon sing for hours didn’t make me an artist. Well, the same is with design. Looking at ideas and trying to make sense of them is not the same as doing stuff yourself. Personally, I knew what good UI was and could point out issues in the not-so-good ones but wasn’t any good at creating them myself. A couple of months in, I was struggling and spent too much time thinking about what to do. Thanks to a colleague, Chandru Arum, I began trying out UIs on my own. Made a lot of rookie errors, to begin with. But with time, I began trying out multiple UIs. Tested them out. Went on to add some micro-animations for good measure? Tested them out. Tried out different flows in each project. Tested them out. To put it simply, I feel I have grown as a designer with every iteration.

Visual design is important. Both in terms of framework and quality.

Being from a design school, I had always been taught about making interfaces usable. Self-taught designers, I observed with time, had this knack of picking up visuals before actually learning about usability. For me, Making UI “pretty” had never been a priority as such. However, in order to invoke that feeling of “awe”, it is imperative that the designs made are not just usable but do need to look good as well. And also, it is not just quality. There is consistency as well. Visuals need to follow a framework across a platform. Every designer cannot set up their personal style. Components need to be reused. That is where setting up a visual language also comes into play. I had the opportunity to work on the design system of a product which helped me understand in detail the need for components and how they should be built. Additionally, this is not just important for design, but the same components being maintained on the frontend makes the entire workflow much easier for all teams involved and also allows new joinees to pick up visuals pretty easily without too much of an effort.

Treat the organisation as your own and it will do the same.

In the 12 months spent here, I have seen a lot of the organisation change in terms of structure and size. An individual tends to feel lost in all of this. However, in their own way, they are one of the wheels of a many-wheeled caravan. And it is important for an individual to feel that each wheel is important for the organisation. Contributing in my own little way, I found myself contributing to the overall goal of the business. The more that an individual values, not just individual growth but the growth of the team and by extension, the organisation, the more the team and the organisation will accept them as an integral cog in the machinery, and they will feel at home.

Own responsibilities. They include more than just design.

Ownership of responsibilities is a core component of not just being a good designer, but being a good individual contributor in any field. In terms of product design, it revolves mostly around owning the entire product end to end. However, in a growing organisation and for someone who is just starting out as a designer, it is more than that. For example, creating a video, a graphic poster, or even getting involved in the arrangement of a party, are not really a part of the job description for a product designer. There might be times when your skills can serve more purposes than you think you are skilled at. Own it up. Own all responsibilities as you would own the work you like.

Adding new faces to the team.

The team, in a rapidly growing organisation, would grow and as a growing designer, I got my opportunity to get involved in hiring new members to the exemplary team a few months into my first stint in the industry. Learning from the experiences of talking to multiple minds with innovative ideas under a constraint, never thought so much could be learnt sitting on the other end of an interview table. It is a constant learning curve and being a part of the whole process being set up was indeed an enriching experience, and it still continues to be.

All illustrations have been made using Humaans by Pablo Stanley

This chronicle of my experiences is inspired by this piece, Reflecting on my first year in the UX industry, written by a colleague and friend, @kshipra_sharma, last year.

I would especially want to thank the aforementioned for their input on the article. A call out to the entire design team at Razorpay for making me feel straight at home in the design industry, as we together solve payments for millions of users across the nation. Expressing special gratitude to @saurabhsoni_ss and @Chettyarun for being the best possible mentors at the beginning of my journey.

A year as a Product Designer was originally published in Razorpay.Design on Medium, where people are continuing the conversation by highlighting and responding to this story.