How to Tell a Senior from a Junior Designer
From design directors at Dropbox, Shopify, Clio, and more
I’m doing a 30m Freeform Q&A Session on March 2nd at 6pm Pacific, join us!
It’s a fantastic time to be a designer. We’re finally starting to receive the kind of attention and value we’ve been clamoring for for years, decades even. With this, there’s a lot of nascent talent trying to find their own way. A lot of designers fly solo on teams without much mentorship, for others they have managers that are product managers and not really focused on human outcomes.
In my time as a product design lead, I was mentored by design directors from some of the world’s most design-forward companies. I wanted to know what they felt separated the seniors from the juniors, the cream from the crop.
From my own experience combined with theirs, here were my findings — note, none of them had to do with experience, but what experience for some could teach them. There are also many who have much experience but learned little, but that’s a topic for another day.
1. Intentionality
Seniors know what to focus on and when. They know how and when to break the rules and when not to. They know when to skip wireframes and go straight to mocks, and when to never deliver mocks and deliver a prototype instead. They know what they’re good at, what they’re not good at and how to fill the gaps in their skillset.
This sounds easy, but in practice it’s incredibly difficult. Here are some examples for both the technical side and the operational side (working with teams):
Technical intentionality
I hinted at this one already, but this has to do almost entirely with how and when you choose certain design steps and tools to fulfill end goals.
Juniors will start with a fixed process, every project. It’ll go something like:
Talk to users
Talk to stakeholders
Create a brief (or be handed one)
Create sketches
Create wireframes
Create prototypes
Create mocks
Ship
Look at analytics
Seniors will look at each step, understand the goals behind each, and change processes & tools based on the project at hand.
For example:
A senior may know that a project has a very clearly defined problem, thus he/she can skip research and go straight to solutions, thereby saving time. Something to note here is that a junior may believe a problem is clearly defined when it’s in fact not — leading to a rushed solution that solves the wrong problem.
Here’s a real example of this happening that I observed one day:
Jr: “I talked to a bunch of users who said the dropdown was confusing, so we’re going to switch to a tab UI pattern instead.”
Sr: “Hold up. Why was it confusing?”
Jr: “They just didn’t understand how to use it.”
Sr: “Shoot them a quick message asking them what about the dropdown was confusing.”
Turns out, users thought the dropdown was confusing because the default value was nothing, but once they selected an option they could no longer return to the default value (nothing). The senior just saved the team from going down the wrong path.
Operational intentionality
The same principles apply when working within teams. Operational skills include things like communication, leadership, risk assessment, and so forth — things not directly tied to the hard skills of designing.
For example, seniors know when to communicate and how, based on the stakeholder and the problem at hand.
If the senior is pitching an idea to product management, he/she may use a slide deck showing how a proposed design could affect the metrics that are important to that department.
If the senior is pitching an idea to development, he/she may break the design down to the parts on a whiteboard that can be shipped incrementally as that’s what the engineering team has been focused on this particular quarter.
This also applies to the senior’s own strengths and weaknesses. A senior should know that he/she is stronger at visual design, and therefore when put on a project with a heavy problem discovery component should seek assistance from someone who’s strength is in that area.
2. Influence & Impact
As I mentioned in an example in the previous section, you can see a senior’s effect when he/she is in a room. Was the senior able to add value to a discussion that would not have occurred without him/her there? Why this is important comes down to some simple math.
If a designer’s output makes the company, let’s say, $150/hr (I would love to think that all designers make a lot more for the company than they cost!). If you increase your output to $200/hr, you’re doing fantastic! You just increased your output by 33%.
But if you’re influential? Your potential is so much more. If you as a senior were able to influence a product team to increase their output by $20/hr, and/or even the design team as well, you’d be looking at an aggregate added output of 100%+! That’s because you leveled everyone else up and added to their own outputs by simply being in the room.
As a side note, that’s why people managers are so darned valuable. Their sole purpose is to level up everyone so their total output is significantly greater than they could achieve themselves.
3. Big Picture Thinking
The third biggest difference that I wanted to mention was to do with how seniors think. Juniors tend to be heads down, thinking in terms of tasks and focused on executing them to the best of their ability.
Seniors think cross-functionally, understand the business goals of what the team is trying to accomplish, and make decisions accordingly. Ultimately, everything anyone on the team does needs to be traceable back to the higher level goals of either making the company more money or saving cost. Juniors rarely can explain how what they do ties into one of those goals, seniors always can.
A senior engineer I used to work with put this so well it’s worth a quote:
As you become more and more senior, you try harder and harder to stop coding.
The same can be said about design. A senior designer recognizes that design is a cost the business is bearing to achieve a specific goal (make the product more desirable). If there is any way he/she can achieve that goal with as little design as possible, then the team should do that!
How this actually influences day to day tasks can be illustrated by a few examples:
Understanding that shipping sooner is actually the biggest business value at the moment, and cutting parts out of the design process (including pixel-perfection) to achieve speed.
Understanding that a part of the proposed design will be incredibly costly from engineering but provide little value to the user, swapping the pattern as a result.
Knowing that a project is insanely risky but has huge upside potential to the business and therefore proposing to the product manager that the team spend an inordinate amount of time on research first.
You’ll notice a lot of overlap between these three distinctions, and I’m sure many design managers can weigh in on more traits like risk assessment, leadership, and more. These were the ones which I felt were the most important, so consider this a primer :).
I’m doing a 30m Freeform Q&A Session on March 2nd at 6pm Pacific, join us!