Product-led growth provides UX with an exciting (and high-pressure) opportunity
I felt sorry for the Junior UX designer working with me. This is probably his first or second UX design job, but he was caught up in a new wave of excitement that most companies might not typically encounter.
We had been caught in the midst of a new buzzword, Product-Led Growth, which meant that both he and I had to shape up to meet the increased demands of Product and Engineering.
That doesn’t mean that it’s not fantastic. On the contrary, Product-Led Growth is the initiative older designers like myself have wanted for ages. However, adapting to this new way, or other high-pressure design scenarios, can be challenging for newer UX Designers.
Here are three tips I wish I knew going into Product-Led Growth companies.
Coming from environments where design cycles might be weeks or months (healthcare in federal UX), Product-led Growth is a breath of fresh air that support UX professionals.
Product-led Growth makes UX one of its core pillars: designing for the end user. You’re also allowed to run user research experiments, have a culture for continuous rapid improvement (i.e., iterative design), and invest in gathering customer and product data to inform decisions.
In many ways, product-led Growth is the idea behind what many successful design startups do: ensure there’s an essential product that users find value in, provide it to them for free, then gather data to help inform how to build or monetize the Product. It’s a proven successful model through companies like Slack, Calendly, and DataDog.
However, working in a company that does product-led Growth can be incredibly hectic. This can range from showing designs (and getting feedback) daily, iterative design cycles of a week or less, and a lot of pressure from your team to work efficiently.
It’s also not uncommon to get messages asking for different versions of your design prototype and an emphasis on getting core features in working condition (in any condition to gather data).
In the old model, UX wouldn’t even be a part of this process: Engineering would throw something together, and then they’d see how people react. However, UX has gotten the seat at the table they’ve always wanted (for years), which means we’re pulled into this hectic process.
Unfortunately, that means that there’s a lot of pressure on you from Product and Engineering because you’re the first point of contact (and a roadblock if you take too long). This is why I felt a little sorry for the junior UX Designer (even though I knew he’d do fine).
We had a solid design system and several senior UX designers (including myself) who’d worked at startups or design agencies. So we were used to the pressure and pace in one way or another.
But if you find yourself in these high-pressure situations, and you might not have all those resources available, here’s what you should do.
Use your design system, or choose an unofficial one
There’s a term in cooking, mise en place, that is critical to working in high-pressure environments. Rather than chop up ingredients in the heat of the moment, when there’s an extensive line of customers waiting, chefs prepare the ingredients hours in advance by cleaning, slicing, washing, and preparing vegetables and meat.
Design is no different. When working in these situations, having design patterns and things on hand to build your prototype allows you to mock up what the team needs quickly.
This is great if you have a design system: in that case, take some time to get familiar with the components you have. Sometimes, design systems aren’t made for designers: the documentation is written for developers. The documentation provided allows developers to understand the coding variables and what to code rather than specific design use cases.
But what if you don’t have a design system (or yours is incomplete)? Use one unofficially and push to get it adopted (or your team to build your own).
My default is Google’s Material Design system when my work doesn’t have a design system. Everything is well documented, along with use cases, dos and don’ts, and more. The other thing is that there are many community plug-ins on Figma for the design system.
Whatever you choose, it’s crucial to choose a design system for one key reason: you need to provide Engineering consistent design patterns to avoid tiny mistakes being built.
I don’t know if this was just the PLG companies I worked for, but when I had minor inconsistencies in my design (like table rows being a few pixels off), Engineering would build these mistakes into the final product.
Remember, Engineering is under just as much pressure to build as you are, which means they will treat your prototype as their source of truth (and build precisely to your blueprint). If there are inconsistencies with the spacing or other things that you would expect engineers to be able to interpret, they won’t.
At the same time, you don’t want to waste time hunting down pixel inconsistencies across different components. There are many free design systems out there that you can use, so make use of them.
I’ve mentioned this before, but I’ve learned the importance of proper version control after embarrassing myself in meetings by loading up the wrong prototype.
Stakeholders have different needs, so you must provide the right design for each. What do I mean?
- Product members might be in discussions not involving you, so they need a stable, end to end, clickable prototype that doesn’t change
- Product owners might want a future-facing design that encompasses features that they won’t build in the mvp
- Some engineering team members want a clickable prototype that only encompasses the work they’ll make this Sprint (I., E. The source of truth they’ll build with)
- Other engineering team members want the detailed nonclickable design workspace that they can inspect for exact details
Keeping these different versions straight requires organizing your pages and prototypes so that you know what to provide each person if they ask. As a result, two standard methods of page organization tend to be used:
- Organizing by Sprint
- Organizing by Feature
Organize by sprint
I prefer organizing pages by Sprint because it allows you to showcase progress. So, for example, you might have a small design slice on a page labeled “January 12th sprint”, which becomes something more fleshed out on the page labeled “January 26th sprint”, and so forth.
This provides an excellent measure of progress that the team can refer back to, but one downside is that you need a straightforward naming convention. For example, UX often works 2–3 sprints ahead of Engineering, so when you’re labeling something “January 12th sprint”, is that the UX sprint for that date or the engineering one?
Organizing by Feature
This is where the other method, organizing by feature, comes into play. This method is about arranging your pages (or prototype), so each page is a separate feature, often matching how teams work on projects in an Agile sprint. The idea behind this is that there are ‘breakout pages’ to look at particular features and the master copy.
However, this can cause problems for Engineering, especially if they need to cobble together several links (which might change as Designers work on them) to figure out what they need to build for a sprint.
Either way, you organize things, it’s crucial to stay on top of this to ensure that each team member is working with the version of the design they need.
However, one more skill you need to learn for these environments: interpreting ideas and re-introducing them through sketching.
Learning to resist bad ideas through sketching
In these high-pressure situations, you must realize that people desperately search for a solution to any problem. Remember, they focus on putting out the products as quickly as possible and delivering some value to get users involved.
Your team members may snowball ideas from one another until you’re designing by committee (or mandate). For example, engineering might suggest a solution that’s easy from the technical side, and Product might run with it and tell you to build it.
It’s your job to resist the pressure (to ensure good UX), but gathering more information and turning it into something visual is the easiest way. Listen to their request, and ask for details, but don’t follow their request to the letter: design something that addresses the problem in a visual sketch, and open the discussion up again for feedback.
One thing I’ve found is that, in these cases, there’s almost no sense in arguing with them before sketches are created. Everyone’s under time pressure to get something out, which is why they’re throwing everything at the wall and seeing what sticks.
This means that if you address their problem with a solution using good UX instead of whatever they cooked up, they’re more than happy to run with it (as it’s a solution to their problem).
For example, if they’re pushing to turn all buttons into icons to save space (and assume everyone knows what each icon is), ask for more details and try to understand the problem (or have them frame it in a way that makes more sense).
In this case, the team might be concerned about ‘row overflow,’ where specific columns might have a ton of information. If that’s the case, consider re-sizing specific columns (or finding other ways of saving space). Then, when you present the visual design, it might turn out that you’ve solved the problem, and the team is willing to go along with your solution.
You’ll want to learn these things if you find yourself in a Product-Led Growth company.
I’m excited about product-led Growth, even if it seems a little scary
Despite the scary and hectic picture I’m painting, Product-led Growth is a fantastic idea that I am a hundred percent behind. It does what many older UX professionals have wanted for a while: it establishes us as a pillar of building products, providing us with a seat at the table.
This means you see larger UX teams, more budgets for user research and testing, and support the iterative design and other design processes that are core to our field.
However, as businesses start to figure out the best processes around this idea, UX Designers might suddenly find themselves facing a lot more time pressure, responsibilities, and more.
So use these tips to organize your environment, make your designs more consistent, and resist bad ideas created due to time pressures. Once you do, you have an ideal working environment incorporating UX into a product’s core decisions.
Kai Wong is a Senior UX Designer, Data-Informed Design Author, and author of the Data and Design newsletter. His new free book, The Resilient UX Professional, provides real-world advice to get your first UX job and advance your UX career.
