What I learned from a year of designing products with 100+ people
VTEX is an online commerce platform with headquarters in Rio de Janeiro, almost 200 employees and 60+ software developers. Our clients range from big enterprise operations to small shops in over 16 countries around the world.
When I joined the team over a year ago, I didn’t really have a lot of experience designing products for the web. Sure, I had enough education and knew how to do design stuff, but no matter how much you train yourself to design things, you will never be prepared for the harsh reality of not being capable of delivering the products you want to.
I fell short of the design work I wanted to ship in the past year. That’s not to say I’m not proud of my team and what we shipped, on the contrary: VTEX Storefront, our new CMS using a whole new development platform, has been released in closed beta and it was the biggest design challenge I’ve ever faced.
The thing is, no matter how many design books I read, how many tutorials I went through or how many conferences I attended, when I wasn’t able to deliver the work the way I wanted, letting myself feel let down was the only thing that allowed me to move forward and learn something from it.
"Letting myself feel let down was the only thing that allowed me to move forward and learn something from it."
I tried to condense some of these feelings below. This is an essay about designing products, written for designers, but there’s some personal insights in here as well. It may also be pretty obvious to an experienced set of eyes, but hey, I had no idea about any of this a year ago.
Managing Complexity
Our job as designers is to organize reality into new forms that were previously inexistent. And to make the concrete things we want to make, we must first understand all the words they hide behind.
Before you wireframe, before you code, before you do a single user flow, ask yourself: What is it that I’m building? Once you have a clear answer on that, ask your team: What is it that we’re building?
Answers will always differ. Bang your heads collectively into a wall until each and everyone of you agree with all the words necessary to define the problem and the product. There will be compromise and the words will evolve over time, but this first step is absolutely necessary. If you avoid conflict, vision will differ inside the team and it will bite all of you in the ass later on.
"If you avoid conflict, vision will differ inside the team and it will bite all of you in the ass later on."
I spent a whole year designing a system with concepts that the team hadn’t fully agreed upon, and it impacted every decision that came afterwards: every turn-around, every refactor, every scrapped iteration and un-merged branch. These are always part of the process, but there’s a difference between a fast-paced iterative process and… well, doing so without a clear direction.
Your first responsibility is to prototype the concepts that will power what you and your team will build. To reduce the complexity of the world around you until it fits in a vocabulary, a wireframe, a back-end architecture or a marketing landing page. Most complex products have poorly defined concepts beneath the hood.
Yes, an airplane dashboard is complex, but you get the idea.
Move Fast and Break Stuff ™
Being the single designer on a team of developers shipping code in React is amazing. I love learning to code, and of course I wanted to be fully integrated with the team on a fast iteration cycle with minimal friction, so doing HTML/CSS prototypes inside React components was an obvious decision from the start.
Not only that, shipping code was the prime directive of the team. This is a fine directive for a software company of our size, but as with everything in life, it’s not that simple.
Time constraints and pressure to ship was so big that my design process was rushed (by myself). I went into coding too fast and made prototypes that didn’t really solve the problems at hand, forcing us to consistently throw them away as we realized they didn’t meet anyone’s needs.
At one point, I got so frustrated with throwing away my fully-coded UI that I started to abstract it in components as I made them, doing an undocumented style guide just to make sure these UI components could be useful later on.
Of course that wasn’t a solution, but a side-effect of the unsolved problem: poorly-defined concepts that lead to well-meaning, but flawed experiences.
Don’t burn steps in your design process. You haven’t read all those boring O’Reilly books for nothing. If the deadlines are too tight, then shorten the scope, break it down in more iterations, make it work the way it should. It’s better to have a smaller product than a shittier one.
Edges of Coding
VTEX has an environment that pushes designers to get their hands dirty on code, and I couldn’t be happier with it. However, after a year geeking out on React, some limitations showed up — and the edges between design and development became more clear to me. The first one being: you are not a computer scientist. And you’ll never be a computer scientist, unless you study to become a computer scientist.
Seriously, what’s up with all this code craze? It’s as if programming is just like learning to ride a bike. Well, guess what… it’s not! Programming is a job that takes a lot of study to be done properly. A junior front-end developer that’s serious about her craft will do in a few hours things it would take me a week to (maybe) get right.
That said, a steep learning curve is a great way to keep you on your toes and allows you to learn as much as you can while designing. And that’s a great thing! Ultimately, as a designer, your job is not to code. Of course this may change from place to place, but if an employer is expecting a designer to ship production-ready A-quality frontend code… that team likely has other issues to solve.
To all designers that work with code out there that are feeling overwhelmed, as I have several times in the past, take a deep breath and repeat:
"This isn’t working. It’s OK."
Now go ahead and change your environment. Because our tools should work for us, not the other way around.
"The job at hand is to deliver a prototype that communicates a solution to be implemented."
The job at hand is to deliver a prototype that communicates a solution to be implemented. If the office network goes down you could write it down as a poem for all I care, just lower the definition of your prototype until you’re: a) comfortable with your tools and b) able to communicate the solution.
Of course the tools at hand will change from team to team, but if you are not comfortable with your team’s toolset, well… you might question if they’re right for you. Otherwise, just get comfortable having a lot to learn!
The Problem is Bigger than the Solution
You will never “design everything”. You will never fix all the problems or meet every user need. If you do — if your product actually reaches 100% of its goals, it probably means you weren’t ambitious enough and so much more could be done. You’re selling yourself short and delivering less than you could for fear of failing.
"Let my bets be bold enough to take the risk they’ll go terribly wrong."
If there’s one thing I want to take from this year of experience, it’s this:
Let my bets be bold enough to take the risk they’ll go terribly wrong.
On practical terms, that means defining a crazy-ass vision at the beginning of the project and boiling it down into smaller, sequential, iterative parts: product and user goals, architectures, flows, features, views, components.
"Define your vision from the outside and build it from the inside."
Define your vision from the outside and build it from the inside. It will let your product grow closer to the large vision you defined on the outset with less chance of losing itself along the way. You may never achieve the vision, but you’ll probably build something good on your way there.
In the past year I’ve made uncountable sketches, hundreds of commits, wrote a bit, attended a conference, launched a beta, interviewed dozens of designers, hired a few — and sometimes failed doing all of these.
Here’s to another year building and failing alongside this amazing team ????
This post was originally published on Daniel's medium profile.
