BA 47/52: Working With Designers (A Non-Designers POV)
Everything Apple has taught me about the Design process and working with Design Teams.
It’s not easy being a Designer.
Engineering Expectation: I will ask a question to design and they will give me design specs with all the details quickly. It’s easy, they just have to draw out the buttons and boxes.
Designer Reality: How do I slot this into the 1000 other questions I need to think about, brainstorm, wireframe, check, wireframe, back to drawing board, placement in the remaining product, wireframe again, design pixels, iterate.
By no stretch of the imagination is this meant as a dig at Designers.
As a matter of fact, having worked closely with some of the most creative designers at Apple, Google, Nike and now Humane, let me tell you - it’s not an easy thing to whip up the magic they do.
If there is anyone in the cross-functional product team that must empathize with design and other teams, it’s us TPMs.
Learn to appreciate the hard work that goes into figuring out how and where that button needs to go; pass on that knowledge, bake it into the project plan, help Engineering and Design work better together.
What Apple has taught me about the Design process
🚨 Fair Warning: I know the Designers will read this and go “that’s not really how it works.” My intention is to give the TPMs a foundation upon which they can build or mold their approach based on the unique approach Design takes at your company.
The Question Or Problem
At Apple, every design conversation I had with the Human Interface team started with a question or a problem. That question or problem can be broad or specific. However, you cannot simply show up to the table and ask Design to “Give you Specs”.
The intention is to establish constraints or context that teams will use to ground all future questions, conversations, and activities.
What is the ideal onboarding/setup process?
Should the desktop UI mirror the mobile app UI?
What is the playback experience for the music app?
Does this color and placement of the “Yes” button have the right intention?
Is this copy easy to understand?
Brainstorm (Boxes and Arrows)
Usually, if the question is straightforward enough, you will get an answer on the spot. However, sometimes it requires thinking, pondering, brainstorming, especially when you are working on 0 to 1 product where no internal reference exists. Designers will spend some time thinking through the question or problem; this will probably the longest part of the entire process. The most common approach to brainstorming we would take is flow charts.
‼️ My Experience and Observation
How well the engineering and design teams work at your company will determine if the brainstorming is a collaborative process or more of a “ask and get” process where design goes off and builds something for you.
Why? Trust.
I have observed that Designers are afraid of involving engineering in the creative process too early because we cannot help ourselves and look at every thing design says from the mindset of “implementation”.
Design will go through many number of ideas before they land on something that feels “good”. I have seen this process go bad so many times where Engineering will see a number of “explorations” Design has done and immediately start complaining that “this is too complicated to implement; they are focused on the wrong thing” which puts Design on the defensive. Likewise, Design can sometimes take too long in this process trying to find that “perfect” design.
One thing neither team will ever have in abundance - time. TPMs can play a huge part in building this trust by setting and managing these competing mindsets - creative versus implementation.
I can safely say that at Apple, for most part, the trust between Design and Engineering was high thus engineering had a seat at the table early.
Wireframe
After much back and forth, once an answer or solution takes shape in the flowchart, Design will move on to wire-framing.
🔔 TPMs: This is your first two milestones in the process.
Wireframe Ready
Implemented Using Engineering UI
The wireframe is the beginning of translating the flowcharts into UI specs. However, this will still not be the pixel perfect spec you are looking for.
Only a limited number of issues will reveal themselves to you in the brainstorming phase. Often times, new issues are found when you start translating solutions in the actual Design specs.
A smart engineering team will look for opportunities to leverage Engineering UI — gritty, basic UI used in place of actual final design specs to continue development progress. This gives Designers actual functional code to play around with to further refine their designs instead of a whiteboard, Engineering critical path is not blocked, every keeps making forward progress.
Final Design Spec
🔔 TPMs: This is your next milestone in the process.
Implemented Using Final UI Spec
Eventually, Design will share the final design specs. Each design team will have their own approach to how the specs are shared. At Apple, we used to get final specs on a shared drive. I am sure with modern tools like Figma, the world is more efficient at sharing.
Design Sign Off For OK2Ship
🔔 This is the most important milestone and exercise that you will do. This will directly contribute to building that trust relationship between Engineering and Design.
OK2Ship Design Spec Review
At Apple, before we shipped any feature, the Engineering, TPM, Design, and often Product Marketing DRI, will review every screen, every button, every copy, color palette, everything and match against the spec. Goal is to ensure the code we ship is what Design included in the spec.
I will make a bet that you have experienced or heard of at minimum one occurrence of Design being upset that Engineering didn’t ship the right spec.
Most common reason for this is break in communication or trust issues. Sometimes, Engineering may make changes to the design because of a code constraint and never communication that back to Design, maybe because Engineering deemed it too trivial a matter to bring back to design. TPMs can help prevent this.
Use this simple design process flow as a starter to build and modify according to how you and your Design teams work with together.
You can also use this simple starter process to build out your own bespoke, company specific design process as your Design and Engineering teams scale.
Yes, there are so many more steps that go in between each of these phases, what discussions to hold, how to track tasks, what to prioritize when, the critical path dependency, strategies to communicate, a lot more. For now, let’s focus on the basics and fundamentals. Maybe there is a part 2 of this piece 🤔.
Until next time 👋!
-Aadil
How is this week’s newsletter?