5 learnings from 5 years in Product Design
In 2017 India, UI/UX Design wasn’t a mainstream profession.
It was talked about, but nobody knew what exactly it was. At the time, I was graduating from one of India’s premier engineering colleges, and my batchmates were wondering why I wasn’t sitting for placements for engineer / business analyst roles, which were all the rage back then. I wasn’t interested; I wanted to pursue this niche field called UI/UX. You can imagine how tough conversations were with my parents around that time.
Five years later, everyone wants to be a UI/UX designer.
People are abandoning degrees and careers across all other design disciplines (graphics, fashion, communication design) to pivot to UI/UX. Even product managers, architects, content creators, and front-end developers want a shot. Demand for UI/UX/Product Designers has exploded, catalysed by rapid growth in the Indian startup ecosystem, and by major product / service companies pivoting to more design-centric business processes.
This has created a huge imbalance in our ecosystem.
On one end is a flood of entry-level designers and aspirants. They have filled their (concept) portfolios with pretty redesigns of once-great products, and case studies of already-solved problems. Most of them have an absurdly rosy and inexperienced view of product design — as if a few well-presented mockups is all it takes to get an entire business to change its trajectory.
On the other end is a drought of “experienced designers”. 99% of actual Product Designers have been in the field for less than 10 years, but they suddenly find themselves labelled as industry leaders.
Now don’t get me wrong; some are genuinely brilliant, and continue to define and evolve our profession in new ways. But unsurprisingly, these people are too focused on their jobs to actually mentor anybody.
Some have (sadly) gone straight to exploiting the incoming class of clueless aspirants, and in the absence of formal and legitimate education are selling them mediocre (or outright terrible) design courses at unreal prices.
In the middle however are folks like me — too young to be pioneers, but too old to be naive. We’ve outgrown the ocean of preliminary knowledge that is being sold to everyone else as industry-defining literature (Don Norman and Brad Frost especially come to mind); instead, we find ourselves frequently looking for guidance from people who’ve stayed ahead of this rapidly evolving profession with timeless nuggets of information.
In that same spirit, I want to share a few things I have come to realise, having worked for 5 years in both product and agency environments. Hopefully, some of them will help both my fellow product designers looking for new advice, and the incoming class of designers who want to get a better picture of what the profession actually entails.
Learning #1: Presentation really makes or breaks your design.
They make or break the profession actually.
In the absence of good presentation skills, your first stumbling block will be the hiring process itself. Your evaluator will give you no grace marks if you cannot showcase your portfolio and past experience properly, or cannot communicate clearly how you solved problems and created a better experience for the end user.
Presentation skills are also critical in aligning stakeholders in meetings, of which there will be many (both stakeholders and meetings). I have seen time and time again how discussions, and subsequently decisions, are steered by how designs are showcased, whether intentionally or otherwise.
A good, smart designer can pivot an entire company’s priorities with a combination of well-crafted designs, a solid presentation deck, and clean delivery and communication while presenting. Conversely, I’ve also seen meetings go very wrong when they start from badly presented designs and mockups.
Expect no one to be convinced you “thought it through” as you frantically zoom and pan around your Figma file to find the artboard they’re looking for. Bad presentation of a design indicates both lack of clarity (because of which you couldn’t structure the presentation well) and a lack of visual prowess (because of which the presentation doesn’t look good and isn’t wowing anybody).
Neither thought is something you want to be associated with as a product designer. Think about it; if you can’t communicate your design clearly to people, and your presentation doesn’t light anyone’s eyes, why will anyone trust you to be a good UI/UX designer — where your job is literally to communicate clearly to people and light up their eyes?
Learning 2: See the bigger picture quicker and earlier.
I have known many designers who approach any project or problem statement with just a basic “IA” or “UX” provided by someone else (usually a product manager or a UX designer upstream in the chain). They then assume hundreds of different things without confirmation, and design exactly the first picture they had in mind when they saw the brief / IA /UX.
These are also the designers whose projects would then undergo months and months of delays and revisions.
When I phrase it like this, the reason for these delays sounds obvious; but in practice, you see designers do this again and again. The tendency to “jump” to a solution before investing some time in fact-finding and research is very real, and I have done this myself for several years without realising it. Each time, it came back to bite me later.
Call this whatever you want — “scoping”, “discovery”, “research”, “cross-evaluation” — it doesn’t matter. What is important is that you do it. Designers who design straight from one document are doing themselves a disservice by limiting their knowledge & growth, and guaranteeing wasted effort. They are also doing the entire project a disservice by not thinking about why the project even exists, and whether the solution presented to them is the only one applicable.
At Urban Company, we have begun rejecting PRDs that jump directly to design requirements; I’d highly recommend other product designers to follow a similar methodology. Refrain the urge to arrive at a design solution early on, and discourage others from doing the same when approaching you.
Dissect the problem statement and the world it exists in. Figure out how big a problem is it, what are the possible solutions (and sort them in terms of ROI), estimate what will it take to solve (time, effort, resources) and the impact it will have on key metrics. If this is done for you, great; if it is not, it is your responsibility.
Learning 3: Learn the basics of your complimentary fields.
No more “should designers learn code” — the answer is a blunt YES.
With a few caveats, of course;
- You need to (usually) learn only the front-end side of engineering. Basic systems and logical thinking is enough for the rest.
- You need to know, but you don’t need to do. Have conceptual clarity about what will be used to code your designs, even if you never need to write a line of code.
- You need to be able to estimate engineering effort basis the designs you’re proposing; you shouldn’t be designing things that need a lot of development for solving a relatively simple problem.
If you have repeated misunderstandings, follow-ups, and disagreements with your engineering peers, know that your lack of knowledge is more to blame here more than anything else.
But your list of “things I should know to be a better designer” doesn’t end at code. Here are some that have made a world of difference in my own work;
Copywriting
UX is more about communication and storytelling than anything else; and good copy is critical to that art. UX copy / microcopy and documentation are two very direct places you will see the benefits of good copywriting and editing skills.
Business Analytics
Even a surface-level understanding will do wonders for your stakeholder management skills (which is in turn crucial for your career growth as a product designer). It will help you dissect the cause and magnitude of problems, track and measure the impact of your proposed solutions, better estimate the company-level effort required, and even sell your design solution better to people who see business growth more clearly than visual aesthetic.
Statistics
In the same vein of “analysis”, the ability to find, dissect, and interpret statistical data is very useful in both the business context mentioned above, and in the context of understanding user behaviour. People say all sorts of things and they point directly to what they aspire to do, be, or have; however, to see what they actually are, nothing beats data. People lie, stats don’t.
Psychology
A beginners course in human psychology can be very helpful in making sure your designs have the desired impact on your users. Any user flow is a mix of emotions and choices faced by your users; and your design will trigger certain behaviours, whether intended or not. Ignore psychology at your own loss.
Branding
At some point, your design will extend directly into a larger brand. Maybe the brand identity already exists and your designs have to conform to it; or maybe the product is the brand, and what you create today will become the basis for brand assets in the future. Either way, to truly create a product that mirrors (or defines) a larger brand, learn the basics of branding, identity, and consistency, and implement them in your designs.
Graphics and motion design
I intentionally placed this at the end of the list to dodge the “it’s just graphic design” trope, but knowledge of good graphic design, 2D animation, and typography are actually useful in codifying aesthetics in your design or guidelines. Plus, it helps to have a better answer to some questions than just “it looked good to me”.
P.S. In my experience, avid followers of comic books tend to be very good at product design, probably due to the overlap of certain skills and themes (graphics, storytelling, composition, identity).
Learning 4: The Pareto Principle is fantastic. Use it whenever you can.
The more applications I looked at for the 80–20 rule, the more it seems like an overarching theme of the universe. In its base form, it just says that ~80% of effects/ consequences/results come from ~20% of causes/actions/sources.
In application, the parallels are endless;
- 80% of crashes are caused by 20% of bugs
- 80% of a design can be created in 20% of the time
- 80% of sales come from / go to 20% of customers/products
- 80% of user time spent will be on 20% of your flows
- 80% of work will be done by 20% of your employees
…and so on.
The Pareto principle just acknowledges in measurable form what seems to be obvious when thought about: not everything matters equally.
In product design, nailing a few key experiences is more important than providing consistent experience across the platform. In practice however, I have seen teams spend weeks discussing and working on each and every edge case compared to the actual “happy flows” (which was closed in days).
Worse, sometimes the design is compromised for 80%+ of users to redress concerns that less than 20% of users will have. TMI, (Too Much Information) is a classic example of this problem; where to try and pre-empt “what if a user wants this / doesn’t know that” type scenarios, designers sometimes create unnecessarily bloated designs that compromise the UX for the majority of users who probably will never have those problems.
In any app, website, project, or flow, find those “key moments” that will stand out to the user, and put at least 80% of your effort into those moments. Then defend the integrity of those moments with all your heart, as you put minimal (but not little) effort into designing solutions for all other possible scenarios. Your designs — and your users — will thank you for your brutal focus on priorities in the long run.
Learning 5: It’s your job to call out the fat in the system.
This one took me the longest to realise, partly because it is a lot less visible in design agencies compared to product companies. But ultimately as a designer, not only should you simplify the product for the users, sometimes you need to simplify it for everyone else in the company too.
Over time, every company goes through iterations, experiments, pivots, and redesigns; the cacophony of moving parts can mean that possibly no one individual in the entire company has a complete idea of how the product works.
While not really a red flag in itself (it’s important for people to specialise in their domain knowledge, and leave the bigger picture to leadership), it creates a lot of ripple effects that add up to become huge chunks of unnecessary processes, wasted effort, and outdated documentations. Some easy examples;
- The problem statement that was given to you might’ve already been looked at years before your new Product Manager joined. Another older team might have already worked on it, or someone might be working on something similar (or even the same thing) from another angle. Older companies with new teams will frequently run into things like this; and disjointed leadership (or siloed functions) only add to the problem.
- People might be spending ridiculous amounts of time doing the same thing over and over again, but not realising it because a) that task is continuously being diffused across different employees at different times, or b) because the tool that exists for speeding up that task is not widely known of, used, or intuitive. Again, very common in companies with weak documentation and relatively newer employees.
- The product is becoming needlessly complicated, and more and more time is being spent explaining its workings to internal stakeholders. This is directly a design opportunity; a subscription model that takes ages for you to understand is certainly not something that you can ever express intuitively to a user. Rather than taking it as a design problem statement, consider addressing the problem at the source itself — ask the team “why don’t we try and simplify this construct?”
This may be vague, for I am still realising in how many ways fat exists within a system/organisation. Unintuitive internal tools, weak employee onboarding, bad documentation, absence of guidelines, excessive experimentation, or competing priorities (“I want more A but I also don’t want to lose too much B”); a lot can add up.
But in tandem with Learning 2 (“See the bigger picture quicker and earlier”), you will often find yourself in a unique position to discover and call out the bloat within a system, and you should. Better yet, just streamline the system; everyone will thank you.
Let’s not forget that we are all young in this exciting new field of product design; a lot of what we will learn in the near future will be fluid, on the fly, and messy. There is no substitute for knowledge obtained through experience; and we owe it to our profession (and all that it impacts) to learn fast, do it well, and share our learnings.
These are some of mine. What are yours?
