An analogy for the designer : developer relationship?
Posted: October 1, 2019 / Last updated: September 21, 2023
Someone asked this question on Quora recently:
What is a good analogy for the designer-developer relationship/workflow?
Unfortunately/fortunately, this question highlights some underlying problems.
A sad state of affairs
The truth is – that most workflows are like this:
There’s a king somewhere and they want to have something created(the client or the boss). They are bored and want to appear like they are doing something important. They’re already rich, so – it actually doesn’t matter what ‘the thing’ is. They hire a bard/court jester or some ‘creative’ (the “designer” as you called it) to come and make it so.
The Jester
Stańczyk - King's Jester.
The jester has lived a life of laughter and applause and brutal beatings. They aren’t entrusted with the power to make decisions on their own, so they suffer the consequences of the king’s emotions. Because of this, they’ve lost their self-respect – and no longer work for joy, but in fear that they will be cast out into the street.
The jester says, “how about this” – and the king says… “No. that’s not right. and so the jester says… “well… what about this?” – and they go on and on and on until the king’s emotions are ‘happy’ or they tire out and just say “ok.”
The Blacksmith
Jefferson David Chalfant - The Blacksmith
Then the jester gets sign-off from the king (who isn’t really qualified for any of this stuff) and puts together a cryptic note(photoshop/invision document) and sends it to a factory of blacksmiths or a single blacksmith in some other country(the developers). There isn’t a lot of context.
The jester just waits. They pace and bite their nails and hope it turns out ok. The king either forgets about the project completely or brings the jester to court and yells at them until the project is done.
The people at the factory try their best to ‘make’ whatever the jester and king have come up with. The ‘designs’ they were sent have a lot of problems that weren’t thought through. It takes 3 times as long as expected and the outcome is still embarrassing.
In the end… there is a thing. And it doesn’t matter – and it doesn’t really do a job / because it wasn’t designed at all. It was just a bunch of anxiety and – a total waste of time. I don’t even want to try to name whatever this process is. None of these people are designers.
Now…
In an actual team of designers – the analogy would be more like a sports team or something. Everyone on the team knows how the game works. They’ve all played each and every position at some point – and now they’ve decided to specialize a bit. I’ll use baseball here.
The pitcher throws the ball to the catcher. the catcher throws the ball to the pitcher. At each phase, the two are working together to accomplish a common goal. There is no king. The crowd is the client / and they enjoy themselves – but they don’t tell anyone what to do. The baseball team knows what to do – and that’s why the client came to the game. There is trust and respect.
There’s isn’t a Designer:Developer relationship – in a good team
In an ideal Design team
If there are just 2 people / then I’d say they are like the pitcher and the catcher on a softball team. They both know how to throw a ball – and how to catch it too. They pass it back and forth and help each other make adjustments as they go. They have a clear shared common goal.
Everyone on a great team is a designer.
-
The Coach did a lot of ‘research’ and ‘content strategy’ and ‘user-testing/research’
-
The Pitcher has been working on their ‘font pairing’ and ‘colors’ – they pass the ideas to the catcher – who interprets what’s working and offers feedback
-
The Catcher is interpreting the visual design and helps guide that information into usable interfaces and then passes it back to the pitcher to iterate
-
The Outfielders are looking for edge-cases – and testing with users
-
Third base is building out data schemes and making sure things are tested
-
Short-stop is double-checking third-base’s work – and trying some new ideas
-
Second base is critiquing the pitcher and working with specific interfaces
-
First base is working with style tiles – and responsive layout ideas
-
Third-base coach is managing the project – and reporting to the coach
-
And the team owner is winning the clients / and marketing the team
-
The crowd cheers everyone on – and gets the value of the interaction
In conclusion
This is the best analogy I can think of right now. I don’t know baseball very well. Sometimes the team is smaller. Basketball has only 5 players, and if you are a long-distance runner – it might just be you and your coach filling in for all the roles.
I think maybe a hospital/doctor team might also work – or a military unit / or any team with a common goal and specialization and teamwork.
If you are working on a team that has some ‘designers’ or ‘creatives’ and then they finish their work – and then hand it off to a ‘developer’ — get out of there now. You aren’t going to learn – and they will fail. Go work for a team that respects Design.
Thoughts from Jared Spool: Baseball vs. Basketball
Jared made some interesting points in a recent talk on Leaders of Awesomeness.
On a baseball team, the roles are different. You might be sitting in the dugout. You might be waiting in the outfield. You might have 5 really great pitches – but only one can pitch at the same time.
On a basketball team, there are loose positions – but it’s all about who can take the opportunity at any given time. No one is waiting. This is a much better metaphor for an agile team.
You should sign up and watch this video! It’s a great one.
Do you want to learn to work on a modern design team?
That’s what our course Design for The Web is all about. Let’s talk about your goals and see if the program is right for you.