Hey designers, it’s time you learned how the rest of the sausage is made
We are a part of something bigger than ourselves.
Effective immediately, all designers are going to be forced to write code. All of us. No exceptions. We were turned into unicorns as we slept last night.
Just kidding, but there is an essential lesson here. The more you know about the people, process, and tools involved in writing code, the better off you will be as a designer. They overlap. The same goes for all of the other disciplines it takes to deliver digital products.
It really does take a village.
In 2007 I was Design Manager at a fintech company in Chicago leading a team of product designers. As a result of a restructuring effort, I was given the additional responsibility of managing the Quality Assurance team. I didn’t know much about QA at the time — other than it was from a faraway place (50 yards down the hall on the south end of the 7th floor). I was given this rationale for the change, “Your team is defining how things should work, the QA team will make sure they work before we release it”.
While obviously a dramatic oversimplification, it seemed annoyingly logical. At first, I wasn’t very excited to learn more about a new discipline. After all, my background was in design, not testing, and I really liked my job. Fast forward two years, and I didn’t end up learning about that new discipline.
I learned about 4 new disciplines instead, and today I am a much, much better designer for it.
I quickly learned the core tenets of QA like manual testing, automated testing, regression testing, the strengths/weaknesses of each, and when to use them. The biggest surprise for me was learning how to write a *good* bug report. I was absolutely blown away by the level of detail needed to do it well (Title, Environment, Steps to Reproduce, Expected Result, Actual Result, Visual Proof (screen recordings, screenshots, text), Severity/Priority).
As I found out quickly, the QA testers were leaning heavily on the artifacts created by design (personas, journey maps, prototypes..etc.) to do their job. Also, I learned the QA team worked closely with the dev team. And the Dev team worked closely with the Data and Release Management teams. I soaked it all up, and I was able to get a much deeper understanding of the collective effort it really took to make it all work.
It was a great reminder that we are a part of something bigger than ourselves. We’re part of a system that relies on collaboration across many disciplines. Once designs leave our control, we’re not done. A lot has to happen to get our product successfully into the hands of our customers.
And together, we are only as good as our weakest link. If you don’t have some understanding of how the other teams around you work, you probably are the weak link. And you are probably creating more work for yourself and your team members.
So make it a priority to learn more about the other disciplines, and you will be a better designer for it too. You’ll also be a better teammate.
Here are some ways you might be able to get started:
- Volunteer to help QA — what self-respecting designer doesn’t want to make sure the final product looks and functions exactly like the designs?
- Spend extra time with the dev team and talk about the workflows, design systems, and tools that facilitate collaboration and communication.
- Offer to write, augment, or revise a user guide, FAQs, release notes, or help materials.
- Ask to listen in on some customer support calls, or review support tickets.
Hey, you know what? Maybe there is an even bigger application here.
Maybe if all we all took the time to learn a little more about each other the whole world might just be a better place.
Just a thought.
