Treating Full Stack Anxiety

I had the pleasure of hearing Joel Califa’s “Full Stack Anxiety” talk at the most recent Designer News NYC Meetup.

His message resonated strongly with me, a self-proclaimed “unicorn” who is just as excited by the typographic nuances of Apple’s San Francisco typeface as he is by the newly introduced spread operator in ECMAScript 6 (ES6).

I was intrigued by Joel’s thesis, roughly summarized in this 2015 tweet.

Joel went on to explain that unicorns (“hybrids”, “designers who code” — take your pick) are increasingly encumbered by higher-and-higher professional expectations to do all the things™. Using the metaphor of the T-Shaped Designer as an example, he poked a hole in the notion that a designer should be expected to simultaneously master illustration, visual design, coding, 3D modeling, and baking a killer molten chocolate soufflé (well, that last one might be an exaggeration).

While it may be easy for some of us to sit back and laugh at these unrealistic expectations, it’s important to note that if left unmanaged, these expectations can send a designer down a path of confusion, self-doubt, and professional paralysis altogether. And as someone who has been there, let me just say:

In my experience as a Product Designer, I have been expected to contribute in three particular capacities:

1. User Experience (UX) Design: understanding users on a core level, discovering/framing solutions to their needs
2. User Interface (UI) & Visual Design: creating interfaces in varying degrees of fidelity, building design systems and pattern libraries
3. Interaction Design (IxD) & Front-End Development: augmenting UI work with finer-grained interaction details, if not actually building out the UI in HTML, CSS, and Javascript.

And through this experience, I’ve most certainly felt the anxiety that Joel describes. Stakeholder and employer expectations to do all the things™ have at times weighed heavily on me, not to mention my own expectations of how, and in what areas, I want to grow as a practitioner of user-centered design. Am I a designer? Am I a developer? Am I a user researcher? These are but a sampling of the questions that kept (and continue to keep) me up at night.

Luckily, Joel offers overarching advice for quelling this seemingly existential full stack anxiety, including: A) ruthless prioritization of the things that make you happy; B) a refusal to chase trends; and C) taking a step back to look at the bigger picture you’re trying to paint in your professional life.

Let me be clear: however trite or simple this advice may sound, it is tremendously important, and, I worry, often overlooked. Achieving the kind of perspective that keeps full stack anxiety at bay takes work and dedication.

But here’s the rub — the one thing that I felt was missing from Joel’s talk was advice on how to confront full stack anxiety tactically, on a day-to-day basis. And I know I’m not the only designer who feels this feel day in, day out (considering the daily release of a new prototyping tool, CSS methodology, or JS library). So, let’s zoom in and see how full stack anxiety might affect your daily routine as a Product Designer.

You and your fellow Product Manager have been working diligently to identify product assumptions and user needs. You’ve validated some of these assumptions with user research, brainstormed lean solutions to whatever problem(s) you’re trying to solve, and now it’s time to start designing the user interface. A few questions and considerations might start to rattle around in your head.

1. Should I sketch by myself first, or do a collaborative whiteboard session with the developers and stakeholders?
2. Hmm, this feature isn’t that complicated…
3. Modal or popover?
4. What degree of fidelity do I need?
5. Flat or material design?
6. Roboto or Proxima Nova?
7. Framer or Invision?
8. cubic-bezier(.42, 0, 1, 1) or cubic-bezier(.175, .88, .32, 1.3)?
9. Shit, Framer is HARD.
10. Ugh, I probably need more fidelity so that the developers will understand: Angular or React?
11. ITCSS or OOCSS?

.: boom :.

Now you’re left with a half-baked Framer prototype, the beginnings of a codebase with poorly factored CSS, and you’ve totally forgotten the user insight that directed your attention to this feature in the first place.

This, my friends, sounds like a case of full stack anxiety.

We designers are blessed — and effectively cursed — by the myriad tools we have at our disposal. By tools, I mean far more than the software we use to do our job.

We write, we sketch, we talk, we code. We push pixels in Sketch, we link views together in InVision, we read Sass documentation over and over again until we finally understand how mixins work. We proudly wear three hats at once, but still fall prey to the notion that our skill-set isn’t diverse enough.

I worry that, in shifting gears so frequently, in worrying about these lofty expectations, we risk losing sight of the thread between these disparate tactics: they are all just vehicles for communicating design decisions. And after all, our currency as Product Designers — our lifeblood, one could argue — are the design decisions that we make rapidly and iteratively.

The crux of our work is understanding users on a core level, and the output of our work are decisions that help: A) fellow stakeholders understand why we are going in a particular direction; and B) fellow developers understand what we need to build in order to deliver users the best experience possible. And the tool you choose to communicate this information — be it a sketch on a post-it note, or a coded Angular prototype — must be a function of the fidelity you need to gain collective understanding of what the team is building and why.

And so, how we arrive at these design decisions is incredibly important. Moreover, as full stack designers, we have lots of tools at our disposal. But we mustn’t reduce this exercise to a superficial choice between this prototyping tool, or that one. Triumph over full stack anxiety thus involves the following, simple piece of advice: choose the right tool for the job. For me, that often means opting for the brief message in slack describing an interaction detail, rather than building out an Angular prototype to communicate the same thing. For you, it might be something entirely different. We ought to ask ourselves continually, “What’s the simplest thing I can do to communicate this decision?”

In any event, Jon Berger, a friend and former colleague at Pivotal Labs, says it much better than I can:

We’re in the business of making design decisions, not deliverables, so ideally all we need is a comment to memorialize that decision. “Make the navigation vertical instead of horizontal”, for example. If we can’t make it clear with a comment, we’ll go to a whiteboard and sketch it up. If that isn’t high-fidelity enough, we’ll wireframe it Balsamiq or Illustrator. And if that doesn’t do it, we’ll move to interactive prototypes in InVision

If one thing is certain, expectations of Product Designers will continue to grow as time goes on. And I encourage you to heed Joel’s call to ruthlessly prioritize the aspects of design that make you happy, both personally and professionally. But when the rubber meets the road, take solace in knowing that a laser sharp focus on delivering user value, and choosing the right tools for the job to communicate your design decisions will help you transcend the muck and mire that is full stack anxiety.