80/20 Practitioners Make Better Communicators

I spent the better part of 2014 working on two redesigns: one for a major pizza chain, the other for a major bike retailer. The five of us working on the redesigns were excited beyond words—two large-scale sites about two things we loved: pizza and bikes! We all wanted to be heavily involved in every phase of these projects to ensure their success. Along the way, we learned important lessons about how to fine-tune that involvement to arrive at a better outcome.

Working with the same team on two simultaneous projects allowed us to experiment a little with our process and compare notes. The ecommerce-driven Pizza Site had a strong focus on user flows, so we began by creating HTML wireframes for every page. What had once seemed like a bunch of grandiose ideas on whiteboards morphed into actual working prototypes. As we moved into design, the prototypes came to life in all their melted-cheese glory. But by month nine of the engagement, as we started to polish up the templates, we realized that we were looking at the third installment of the same redesign.

This isn’t an unusual occurrence. Teams often inadvertently recreate designs multiple times across phases; the end result looks almost nothing like what the team set out to achieve. What causes this disconnect?

In my experience, it comes from insufficient communication among teams with varying skillsets. Some teams are composed of specialists who all want their ideas and voices heard (yielding vastly different results) while fighting for time, resources, and budget. Alternately, when a generalist works on the entire site, they risk getting spread too thin; the struggle to explore and iterate can produce stale, predictable solutions. Either too much specialization or too much generalization can overwhelm practitioners (and budgets)—and neither approach works.

How to become an 80/20 practitioner#section2

Luckily, there’s a better way. When designers and developers (and entire web teams) work closely together with flexibility and shared understanding, they can use their time and resources more efficiently and creatively. Whether your process is waterfall or agile, a solid team foundation applies to everyone: it allows you to shape a solution that benefits all teammates on a project.

To avoid the mistakes we made on our Pizza Site process, we balanced our responsibilities differently with the Bike Site. We became what I call 80/20 practitioners, focusing 80 percent of our time on our own respective strengths while distributing the remaining 20 percent across other disciplines to benefit the entire project.

80/20 collaboration is about people. It’s about passions. Sounds great, right? So, where do we start?

Establish the foundation#section3

Being a good practitioner means seeing beyond yourself to your team’s broader needs and goals. While molding your process, it’s important to maintain an open, honest discussion with your teammates. Take a comprehensive inventory of the people on your team. Instead of labeling someone a “designer” or a “developer,” take stock of their true skillsets and passions. I’ve worked with amazing graphic designers, amazing UX designers, and amazing interaction designers, all of whom had the same title: designer. What works depends on the person.

We’ve all heard the argument that designers need to code. And while that might be ideal in some cases, the point is to expand your personal spectrum of skills to be more useful to your team, whether that manifests itself in the form of design, content strategy, UX, or even project management. A strong team foundation begins by addressing gaps that need to be filled and the places where people can meet in the middle. This is also how you, as a practitioner, can identify where you should develop your 20 percent of surplus abilities for a given project.

If you imagine your team as a spectrum of skills, each person should have a skillset that covers one part of that spectrum (overlapping to some extent with another part). Let’s pretend this spectrum goes from graphic design (red), to code (blue), with every shade of purple in between. As a designer, I span from the reddest of reds to a reddish purple. That leaves the rest of the purple and blue to be picked up. Let’s say my team includes a designer/developer hybrid, Ava, who is all the varying shades of purple. And let’s say I also have a strictly blue backend developer, Carter, on my team. In this instance, we’ve covered all our bases. If it was just Carter and me, though, we’d be left with a significant void in the middle. We would need either to extend our 20-percent skillset into the purple area or to bring in an additional person to bridge the gap. The spectrum’s endpoints will vary from person to person and team to team.

Strengthen weaknesses#section4

Whenever someone told me, “You should code!” I would think: “But Developer McCoderson can do it so much better and faster than I ever could!” Which was true, so I continued my deep dive into design. Over time, though, working very closely with my developers every day on the Pizza Site, my interest was slowly piqued. Once I started incorporating HTML wireframes into my design process, I began to see how it benefitted me. I could make faster content updates, my layout was automatically responsive, and I could focus purely on content hierarchy rather than worrying about resizing boxes every time content changed.

The more I realized that coded deliverables could be design deliverables, the more I understood that I could get interactions in front of a client earlier. Animations, dropdowns, popovers, etc.—these things are design. We want the client’s feedback on this early, because seemingly minor details like hovers reflect the brand and reinforce the design just as much as an image or color choice do.

This discovery was so liberating that I actually wanted to include code in my process from then on because I preferred working that way, not just because I thought “This will make me a better designer.” I now catch myself voluntarily reading about things like inline SVG and the picture element and almost don’t recognize myself!

Take a candid look at your process and see where you want to expand your 20 percent, not where you think you should expand it. Let’s go back to Carter, the backend developer, for a second. Maybe he wants to improve his front-end skills—but by “front-end,” does he mean his code or his design eye? What’s missing is probably not a talent for writing beautiful DRY code, but rather the ability to recognize design nuances. Maybe the place to start is by reading articles about typography or checking out other design resources, instead of plunging into JavaScript.

Once you start recognizing these secondary areas, you can begin to take your newfound interests offline and look into different meetups or talks than you’d normally attend. I discovered that nothing helped me improve my 20-percent skills more than simply befriending wildly talented developers, both in and out of the workplace.

Learn from each other#section5

The developer on the Bike Site team created a Grunt file to accommodate our entire team’s needs, including design deliverables and how we handle wireframes. Once everything started being delivered within a code-based project hub, we were all on the same page—literally. We could jump in and help each other as necessary, especially on stressful delivery days. Even the project manager was able to use and update the hub.

And the developers learned from me, too. Having them involved from day one meant that they were included in a lot of our design reviews. They began to understand the thought process behind our design decisions, and everyone could holistically understand the system we all were building together. When we began to figure out the wireframing and user-experience part of the site, every member of the team had behavior- and experience-driven suggestions that found their way into the project, both in terms of how it would ultimately look and how it would be built. With everyone involved from the beginning, new ideas that previously never would have been considered cross-pollinated the deliverables—whether it was a developer suggesting an out-of-the-box design pattern or a designer creating a performance budget.

When these conversations happen, barriers between teammates gradually fall away. You’ll probably suggest tools to one another and start to merge processes; in that merging, a new collaborative process will take shape. When we borrow one another’s tools, we begin to learn their benefits and how they may work for our own needs, and we ultimately start speaking the same language. Being aligned on objective project goals helps to keep reviews on track and to more easily settle discrepancies. It isn’t about making anyone’s job easier; it’s about focusing on what’s best for the project. Shared process isn’t something that you can just decide to do; rather, it emerges from learning how another person works.

Let go of ego#section6

To rapidly take a design to code, the overall direction needs to be mostly approved by the client. I say “mostly” because the best iterations happen in the browser once we begin interacting with our designs. This is where our 20-percent-spectrum overlap really kicks in. There will be holes in the design that need to be filled, and it’s up to the developer to create a useful roadmap for the designer to iterate on. Imagine that an early homepage concept is approved and we jump into developmental iterations, but I haven’t had a chance to style the navigation dropdowns yet. I love it when developers take a stab at styling these things. If need be, I can always tweak details that feel off to me. When developers have some design sense, they are able to jump in and make design decisions that the designer may not have considered in a fluid layout or behavior. Designers love to be perfectionists, but we need to learn to let go and not be afraid to allow developers to jump into coding a template of an “imperfect” mockup.

There’s nothing wrong with piece-designing parts and modules as the developer finds holes in the page or media queries. As Dan Mall has stated, it’s about deciding in the browser, not designing in the browser. Everything might not be figured out yet, but that’s okay: we’ll figure it out together. Our websites are fluid; our process should be, too.

Shaking up a process isn’t easy#section7

Change can be hard for any organization, especially when strict guidelines are in place for current processes. You have to work toward breaking down any barriers in communication—whether by getting to know a new teammate on a new project, working within your organization to dissolve silos, or trying to introduce a new workflow idea to your boss. A malleable process is a strong one.

The best place to start is with your project manager. It’s difficult to fit a new process into an ongoing project retroactively, so try to address this at the planning stage. If you’re about to begin a project, make the manager aware of your ideas and how the project plan could be shaped a little differently. It’s important for the project manager to understand the plan so that they can set the expectations with the client accordingly. It’s equally important for them to understand how the timeline will be affected, as it may depart from the typical flow your team is used to.

In large organizations, managers may need to run ideas past the managers of other departments. See if your next project can be a trial run for experimenting with a new process, and volunteer to head the initiative. Samantha Warren gave a fantastic presentation at An Event Apart on getting design ideas moved through an organization. If this doesn’t seem feasible, try building relationships with your counterparts yourself. See if they are open to trying new methods and working more closely together. If you get multiple people on board, it may be easier to convince the powers that be to try something new. Teams organically working well together are a powerful demonstration of just how effective collaboration can be.

Everybody benefits#section8

Dive deeply into your passions while understanding the moving parts around you. Mastering your specialty is not only crucial for professional development and personal satisfaction, but it will also serve your team as you help to stretch that spectrum further. Projects benefit from experts who understand the whole while focusing on their strengths.

When we speak openly about shared end goals, our teamwork gets stronger. When we jump in and help out on cross-discipline deliverables, our teamwork gets stronger. Most importantly, when we combine our collective strengths and work together fluidly, it gives us the perfect recipe for an amazing project.

Remain true to your passions, but take the time to learn something about the skillsets of others to help you craft a unique team dynamic. The 80/20 guideline is a place to strive for—a place where we push our own skills and passions while rounding out our knowledge so that we can work better with our teammates. Being an 80/20 practitioner makes a stronger you and a stronger team.