I spent this past week in New York City, when it is Ramadan, Passover, and Easter all in the same weekend—the three-peat of monotheistic religions. The trip on this weekend was not by design but poor planning on my part. Serendipitously it thematically aligned with my intention of creative renewals and rejuvenation.
It’s natural to reflect on the past when you catch up with old friends or coworkers. In one conversation, we went way back when I was an individual contributor (IC). It's been seven years since my day-to-day was working on designs and shipping features. When I joined One Medical, I joined as an IC after a break from management. I believe that it should be normalized to switch from an individual contributor or manager, but that’s a different issue for another day.
My colleagues often called me "an engineer's designer" since I loved working closely with developers and had an interest in writing code. I intentionally sat by the software engineers in the offices to work closely on design and implementation together. If there is a phrase that I despise more than anything, it’s “design hand-off." I don’t believe in hand-offs. The work is continuous iteration together from idea to shipping. In this issue, I’ll share some of the myths of software engineers and lessons I learned from incredibly smart programmers.
Debunking myths of software engineers
Like designers, not all engineers are built the same. That said, there are some generalizations about developers that have become stereotypes. I’d love to de-bunk it with you.
Engineers don't care about design
I cannot think of a single engineer who I ever worked with that didn’t care the product they worked on looked like rubbish. Many engineers value design—some have more of a knack for doing it themselves and others need help from designers. There are a lot of memes about design vs. engineering and I find them very harmful to the credibility of our craft. Some engineers may not have enough information on how the design should be implemented or need further guidance. Sure, you might work with a few engineers who simply don’t care and I argue that the majority do. This is why I believe when a designer understands the material they’re working with, better outcomes can happen because there is more of a common language and you can close the gap on iteration. In this case, the material is code. When you work with a software engineer, show her how you’re thinking of design and ask her what you should learn more about how the code is implemented. Great things will happen.
Agile gets in the way of great design work
There is nothing that’s more untrue than saying agile is the reason great design doesn’t get shipped. The reason we might feel is way is because most companies aren’t practicing it correctly—usually a combination of Waterfall and Agile that we like to call Wagile. In fact, one of the principles of the agile manifesto states, “Continuous attention to technical excellence
and good design enhances agility.” Who isn’t on board with this?
When I worked with an ex-Apple engineer on a new product idea, I got a taste of how good design can be practiced with agility. I remember this engineer, someone who I would later call a good friend and mentor, relentlessly iterated. I was working on designs for the initial interface of the app we’d prototype. As I took a small break, he tapped me on the shoulder and handed me an iOS device. It was the first build of the initial screen I was working on! I was in disbelief how fast he was working. Each build, we’d walk through the interaction, discuss what can be improved and tweaks we could make, and I’d keep working on the designs. When it came time to think deep and explore on areas we couldn’t decide on, I’d work on another track of work while he started building out the data model or something else that could be picked up. To this day, this type of collaborate is my favorite way of working.
Understanding the customer is for designers and researchers
There’s often a belief that engineers don’t care about the end customer—that all they care about is what tech stack the company is using. Software engineers want to make an impact in a positive way—building things that benefit humanity.
When I was at One Medical, our software engineers shadowed a lot of customer visits and were involved with Design and Research. I recall a trip when Eliza, one of our software engineers, observed a bug in the workflow as one of the clinicians was using the product. On her flight home to San Francisco, Eliza was able to submit a pull request and fixed the bug.
Lessons I learned from engineering
Though this list does not include all lessons I’ve learned from software engineers and engineering managers I’ve worked with, here are the five most impactful lessons.
Breaking down work is good planning
I vividly remember the first time I worked with an engineer to break down work. In this case, it was my co-founder Adam as we were building a product. We created the feature sets and wrote the user stories together. It was so eloquently broken down into the pieces of functionality, edge cases, and prioritization of where to start first. After many revs of building products, it's almost muscle memory on what's needed to build out an authentication workflow or CRUD actions in a profile page.
Understanding how to break down work helps with planning and sequencing. It’s beautiful to see all the aspects to create a piece of functioning software—never gets old.
System design for scale and evolution
Designing software as systems that can scale or evolve is an important skill for designers to have, especially as they grow in their careers. The more senior one gets, the more you’ll likely touch the architecture of how things are created. Understanding some basics such as the difference between monolithic apps and micro services helped me consider implications of certain design decisions.
We might forget that the idea of reusable component software is something that comes from engineering. Working with software engineers on system design taught me to consider how the product evolves over time and not only the current manifestation of it.
Intention setting keeps work on track
Jeff was an engineering manager who I previously worked with. He was so skilled at intention setting, not only for the team he managed, but himself. In our 1:1s, he’d have the entire week mapped out. Certainly, plans change, but if you can set intention that is predictable, it makes you and your team more effective. After setting intentions, using standup and other rituals effectively helped course correct—like having a coach on the sidelines.
With the busyness of the world, I’m finding intention setting important to make time for—blocking out my Monday mornings to plan out the weeks of work.
Prototyping and spike projects are forms of “design to define”
If there was one favorite phase in the product development process for me as an IC, it was product discovery—the art of identifying new opportunities and prototyping your way there. I call it “design to define” where you create prototypes and spike projects to help make decisions. In addition to this work being impactful, I personally think it’s so fun. One of the best projects I worked on was an app for a consumer startup making a lot of headlines right now. The team was only me on the design side and two engineers, and we prototyped the crap out of it to start—building proof of concepts to fund the idea for this particular client.
Working this way taught me to get deeper in the code and how prototypes could be more expansive than clicking through screens.
Quality starts with performance and usability
Designers are responsible for ensuring teams ship a high quality product. Though the interface is important, quality starts with performance and usability. Working with engineers showed me the importance of optimizing for performance, such as load management of data and areas that can result in delays in the product experience. It doesn’t matter if you have a pixel-perfect design if the app crashes or lags in certain area. I learned to sweat the details of the interface, such as accessibility, optimal tap targets, and looking at latency as a metric to improve. I also feel spoiled that I worked with some of the best QA engineers throughout my career—one who recently joined Webflow and I’m so excited to work with her again!
Building software not “us vs. them,” it’s only “us”
The relationship between designers and engineers is often framed like the rivalry between cats vs. dogs. When cats and dogs work together, incredible things happen.
I recommend three books about engineering that you might enjoy:
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Dr. Nicole Forsgren, Jez Humble, and Gene Kim. It’s technically a DevOps book but covers great concepts around building software and continuous delivery.
An Elegant Puzzle by Will Larsen, a wonderful book on engineering management.
Designing from Both Sides of the Screen: A Dialog Between a Designer and an Engineer by Ellen Isaacs and Alan Walendowski.
To all the software engineers and engineering managers I’ve worked with in my career, thank you for making me a better designer and product builder.
Tweet of the week
Congrats, Dezzie on being selected as a juror on Core77’s Design Awards in the field of Interaction Design!
Hype links
Interesting links I read this week or references in this issue:
Steve Jobs's 3-Point Formula for Leading Effective Meetings Was Brilliant. We Need to Get Back to It
One of the big reasons I believe RSS is the most important internet technology in the world