From a grad student to a product designer
My journey as a designer in 2016.
2016 was a year where I experienced many facets of a designer’s journey — starting with job hunts, working on a semester long capstone project, tackling design challenges for interviews, portfolio and interview preparation, landing a job and working as a designer on an enterprise security product. The shift has been crazy, the journey has had its ups and downs, and the learning has been steep. The pointers below are reflection notes I had jotted down over the course of the year — thought it might be helpful for young designers out there.
1. Job Hunt
The year began with job hunts. I had been turned down by Google in December 2015 after a stressful three month long interview process. I was pretty low on confidence. I took a month off of hunting jobs trying to figure out what I was looking for in a company. Amidst stressful deadlines to find a job, this decision was pretty bold and it helped me reflect and think about myself as a designer. I did end up scoring a gig that has kept me satisfied and happy. So, I guess this time to rejuvenate did really help.
Be picky
At one point in my job hunt, I had received 3 job offers and none of them piqued my interest enough. Either the product didn’t excite me as much or the team did not seem like a great culture fit. I turned them down which seemed like a crazy decision back then, but when I look back, I think, it were the risks that motivated me to search harder. When I started turning offers down is when I realized that I needed to filter my application process. I stopped applying to every open position and started researching diligently about the product and the companies as such.
Retrospecting my interests and skills as a designer helped me search for roles that aligned with my goals.
Some of the things I looked for in a company—
Design-driven environment and mentor culture
This was my biggest requirement. I wanted to work in an environment that valued designers. I’ve noticed that a team that values the design process definitely consists of people who can be great mentors.
Grad school made me realize that mentors shape young designers to a great extent.
At times I’ve had bad mentors, and sometimes some real amazing ones, and when I look back, the projects that had good mentors were overall more successful. I cannot stress the need for good mentors. This importance to mentors has recently gained traction with the concept of Holiday Office Hours.
A broader role
A lot of the teams I interviewed with had siloed structures where the research team was isolated from the interaction design team. I realized it was too early in my career to jump into a role that specializes on one aspect of the design process.
I wanted a team that expected me to be a part of the entire design process — ranging from research, interaction design, visual design to validation.
I wanted to get my feet wet with all the different aspects of the design process, and gradually decide what I really want to delve deeper into.
Over-prepare for interviews
Design interviews needs immense preparation as well. When we think about how we form opinions and ideas about a topic, it’s only with very constant immersion that we form a solid judgement. The same applies for any design related activity. Some of the design tasks one needs to prepare themselves for —
- App Critique — rip apart an app of your choice. It can be a web or a mobile app. Make sure you pick something that the interviewer would have heard about as well. Picking something that is vague will not help the interviewer as your thoughts might not resonate with their opinion. Analyze what is good about it? What is bad? How can it improve? Why do you think certain decisions were made? What business and technical constraints can you think about that might have gone behind certain decisions?
- Whiteboard design challenges — I wrote a detailed article on how to tackle these. This is a chance for companies to understand how you think on your feet, how can you tackle a problem in a time-sensitive environment. How do you think about constraints?
- Portfolios Reviews — From my experience interviewing, I have always felt this was the hardest type of interviews. Most of these were conducted remote. It is a great challenge to sell yourself as a designer by walking interviewers through one or two projects. After making a gazillion mistakes, I noticed that interviews that felt more like a conversation were more successful. That is when I started engaging the interviewers while I explained my process. I started tying it back to the nature of their work. This helps with forming a connection between you and the team.
Learn to network
This seems very obvious but I ignored this important step for the most part of my job search. I applied to a lot of companies but later realized understanding a team is more important than just volumes of applications. Reach out on LinkedIN, network with alumni; talk to designers, understand their process and work. Every designer loves to talk about their process and reaching out definitely would be fruitful.
2. Explore design trends to form an opinion
2016 saw a lot of interesting design trends — designing conversational UIs, designing for VR, apps going completely contextual by learning about users etc. I did a mistake by being overly skeptical about most of these trends. I saw them as a fad that would pass over time. On reflecting, if I were to relive through these emerging trends, I would jump head-first and explore what the emerging hype is all about.
I realized dissing new trends without actually trying was a very ignorant move that a designer cannot afford.
It was only after I explored designing for conversational interfaces, I understood its potential and the hype. Is it going to be super successful? Only time can tell. But do I have an opinion about how they have to function in order to be successful? Yes, because I tried my hands on it. I’d not have a definitive idea about it if I had remained a skeptical critic without actually trying.
I have started trying Figma out recently, and I see the potential of this tool being useful in a collaborative environment of multiple operating systems. Teams that use both Windows and a Mac or teams that don’t use a Mac but require a tool like Sketch.
3. Learn how to research in design school
If you are finishing design school this year, you most probably are going to look for jobs very soon. Design school is the last place where you’d probably find people with a design mentality all around you. No, this does not mean that companies don’t have a design oriented approach to solving problems, but not all stakeholders you work with would be thinking through the lens of a designer. Hone your skills as a designer while at school by giving importance to research and process. Drafting a rationale for every single decision made would help with a breadth first framing of the solution and its nuances in your head first, before you can explain it to other people. Learn to synthesize research — helps in very valuable documentation that validates decisions.
4. Explore different tools
I spent most of my year learning FramerJS. This has been extremely rewarding for creating proof of concepts.
Try to pick a tool of your choice that fits well with your workflow.
I tried various tools throughout the year and that has helped me understand the nitty-gritty of motion design.
We see flamboyant animations on Dribbble and think “Oh, I wish I worked on an app like this”. It took me a while to realize that most apps out there have nothing close to what you see on Dribbble. All that jazz might help in portraying what you are capable of, but once you start using these tools to actually build stuff that get shipped, you’d realize the flamboyancy is eventually mellowed. It will be awesome to get a sense of all the tools out there, understand their strengths and shortcomings, and creating a workflow that best suits your needs.
5 . The shift from school to a job
Working with Product Managers
There has been a great shift in the way I think about a product after working closely with a product manager. The business needs and some of the constraints it poses is invisible to us as designers. For the most part of my time spent with PMs, I tried to bring out the inconsistencies and designed to make them in line with the brand and the rest of the product. Little did I fathom about the priorities of the business. It took a while for me to accept the fact that the inconsistencies are going to remain for a while until other higher priority items are completed. Product managers are not designers, they have a whole set of other problems that need to be solved that focuses on keeping the system stable. And that is the foundation of any good user experience.
Constraints in theory are checkpoints in design.
Every constraint can be thought of as a checkpoint. As and when you hit a checkpoint, you can stop, reflect, and think about what has to be done next to achieve that final goal of the product.
It is important to have design opinions over political opinions. For example, instead of “I think the engineering needs to work a little more to get this sorted”, think “This user-flow makes for a better experience and we should think about how to ship this ideal flow.”
A lot of compromises on the flow/experience is made while working towards satisfying business requirements. It is important to understand that the MVP will not be able to ship the ideal experience you would like to have on the product; at the same time it is important to document the ideal experience, and eventually make sure it moves up the priority list. This is something I am still working to improve, and it is way harder than it sounds.
Design for users, not for features
It is extremely easy to get caught up in understanding user stories from PMs, creating flows to satisfy those stories, and creating mocks to represent the interface for a feature. This process is a mistake designers should avoid like the plague. Before we start thinking about how to design for user stories, we should try analyzing the stories and point assumptions made while these were documented.
Try getting in touch with customers to validate these assumptions. This was a route I did not take at first.
I was just creating flows for stories drafted by PMs who have spoken to users — these stories need not necessarily represent the apt picture of user-needs. This does not mean we are pointing fingers at anyone; it just means that we are putting on our designer hat and empathizing more and understanding the underlying problem.
A side project is important
This is something that happened serendipitously to me at work. Take up a side project that you can jump to when you need a change in scene. Ask your manager for a project that has been in backlog for a while.
What works out better is if the project you pick is more research oriented.
This for me, was making our product accessible to all types of users. This has been challenging, helped me when I felt the creative juices were not flowing enough to solve problems on my primary project, and definitely helped me empathize and design for a broader audience.
Code Setup
This is something I have been trying to be more proactive about and would not say I have succeeded as much as I’d like to. I have the code environment setup and create front-end prototypes to validate designs, but for the most part, this stays on the backburner. Trying to be conscious about including actually working prototypes in the process will help with better communication with the engineers.
The pointers above are a personal reflection and by no means should be considered as something written in stone. I believe, penning it down and consciously striving to make improvements to these aspects, however small they might be, would help in the long-run to design better products.
