{"id":4376,"date":"2016-11-14T10:30:47","date_gmt":"2016-11-14T10:30:47","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=4376"},"modified":"2016-12-03T14:34:58","modified_gmt":"2016-12-03T14:34:58","slug":"lessons-year-designing-products","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/lessons-year-designing-products\/","title":{"rendered":"Lessons from a Year of Designing Products"},"content":{"rendered":"

What I learned from a year of designing products with 100+ people<\/h2>\n

VTEX<\/a> 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.<\/p>\n

When I joined the team over a year ago, I didn\u2019t really have a lot of experience designing products for the web. Sure, I had enough education and knew how to do design stuff<\/em>, but no matter how much you train yourself to design things<\/em>, you will never be prepared for the harsh reality of not being capable of delivering the products you want to.<\/p>\n

I fell short of the design work I wanted to ship in the past year. That\u2019s not to say I\u2019m not proud of my team and what we shipped, on the contrary: VTEX Storefront<\/a>, our new CMS using a whole new development platform, has been released in closed beta and it was the biggest design challenge I\u2019ve ever faced.<\/p>\n

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\u2019t 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.<\/p>\n

<\/div>
<\/svg><\/div>

\"Letting myself feel let down was the only thing that allowed me to move forward and learn something from it.\"<\/p><\/span><\/blockquote>\n

I tried to condense some of these feelings below. This is an essay about designing products, written for designers, but there\u2019s 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<\/em> a year ago.<\/p>\n

Managing Complexity<\/h2>\n

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.<\/p>\n

Before you wireframe, before you code, before you do a single user flow, ask yourself: What is it that I\u2019m building?<\/em> Once you have a clear answer on that, ask your team: What is it that we\u2019re building?<\/em><\/p>\n

Answers will always<\/strong> 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.<\/p>\n

<\/div>
<\/svg><\/div>

\"If you avoid conflict, vision will differ inside the team and it will bite all of you in the ass later on.\"<\/p><\/span><\/blockquote>\n

I spent a whole year designing a system with concepts that the team hadn\u2019t 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\u2019s a difference between a fast-paced iterative process and\u2026 well, doing so without a clear direction.<\/p>\n

Your first<\/strong> responsibility is to prototype the concepts<\/strong> 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.<\/p>\n

Yes, an airplane dashboard is complex, but you get the idea.<\/em><\/p>\n

Move Fast and Break Stuff \u2122<\/h2>\n

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.<\/p>\n

Not only that, shipping code<\/em> 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\u2019s not that simple<\/em>.<\/p>\n

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\u2019t really solve the problems at hand, forcing us to consistently throw them away as we realized they didn\u2019t meet anyone\u2019s needs.<\/p>\n

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.<\/p>\n

Of course that wasn\u2019t a solution, but a side-effect of the unsolved problem: poorly-defined concepts that lead to well-meaning, but flawed experiences.<\/em><\/p>\n

Don\u2019t burn steps in your design process. You haven\u2019t read all those boring O\u2019Reilly 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\u2019s better to have a smaller product than a shittier one.<\/p>\n

Edges of Coding<\/h2>\n

VTEX has an environment that pushes designers to get their hands dirty on code, and I couldn\u2019t be happier with it. However, after a year geeking out on React, some limitations showed up\u200a\u2014\u200aand the edges between design and development became more clear to me. The first one being: you are not a computer scientist<\/strong>. And you\u2019ll never be a computer scientist<\/strong>, unless you study to become a computer scientist<\/strong>.<\/p>\n

Seriously, what\u2019s up with all this code craze? It\u2019s as if programming is just like learning to ride a bike. Well, guess what\u2026 it\u2019s not! Programming is a job that takes a lot of study<\/em> to be done properly. A junior front-end developer that\u2019s serious about her craft will do in a few hours things it would take me a week to (maybe) get right.<\/p>\n

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\u2019s a great thing! Ultimately, as a designer, your job is not to code<\/em>. 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\u2026 that team likely has other issues to solve.<\/p>\n

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:<\/p>\n

\"This isn\u2019t working. It\u2019s OK.\"<\/em><\/p>\n

Now go ahead and change your environment. Because our tools should work for us, not the other way around.<\/p>\n

<\/div>
<\/svg><\/div>

\"The job at hand is to deliver a prototype that communicates a solution to be implemented.\"<\/p><\/span><\/blockquote>\n

The job at hand is to deliver a prototype that communicates a solution to be implemented<\/em>. 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\u2019re: a)<\/strong> comfortable with your tools and b)<\/strong> able to communicate the solution.<\/p>\n

Of course the tools at hand will change from team to team, but if you are not comfortable with your team\u2019s toolset, well\u2026 you might question if they\u2019re right for you. Otherwise, just get comfortable having a lot to learn!<\/p>\n

The Problem is Bigger than the Solution<\/h2>\n

You will never \u201cdesign everything\u201d. You will never fix all the problems or meet every user need. If you do\u200a\u2014\u200aif your product actually reaches 100% of its goals, it probably means you weren\u2019t ambitious enough and so much more<\/em> could be done. You\u2019re selling yourself short and delivering less than you could for fear of failing.<\/p>\n

<\/div>
<\/svg><\/div>

\"Let my bets be bold enough to take the risk they\u2019ll go terribly wrong.\"<\/p><\/span><\/blockquote>\n

If there\u2019s one thing I want to take from this year of experience, it\u2019s this:
\nLet my bets be bold enough to take the risk they\u2019ll go terribly wrong.<\/p>\n

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.<\/p>\n

<\/div>
<\/svg><\/div>

\"Define your vision from the outside and build it from the inside.\"<\/p><\/span><\/blockquote>\n

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\u2019ll probably build something good on your way there.<\/p>\n

In the past year I\u2019ve made uncountable sketches, hundreds of commits<\/a>, wrote a bit<\/a>, attended a conference<\/a>, launched a beta<\/a>, interviewed dozens of designers, hired a few \u2014 and sometimes failed doing all of these.<\/p>\n

Here\u2019s to another year building and failing alongside this amazing team ????<\/p>\n

This post was originally published on Daniel's medium profile<\/a>. <\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

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\u2019t really… Read More ￫<\/a><\/p>\n","protected":false},"author":51,"featured_media":4588,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-4376","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-viewpoint"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n