A year as a Product Designer
Articulating the experiences of my first year in the design industry
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 of the individuals starting out and the teams getting designers getting into the industry for the first time.
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 focussed 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 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 onto 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 of 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 an intriguing article on the matter 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 onto 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 it 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 Invision
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. Expressing special gratitude to @saurabhsoni_ss and @Chettyarun for being the best possible mentors at the beginning of my journey.
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.
