Relationshipping
How relationships are the key to shipping great digital products.
Intro
I recently had the pleasure of interviewing for a potential new role. In my main interview with design and product peeps, whilst talking shop, I espoused the virtues of a solid, equitable, 3-way relationship between design, product and engineering.
A professional ‘ménage à trois’, a relationship between 3 equal parties, in the spirit of setting the gold standard of digital product delivery.
So I propose this natty portmanteaux: ‘Relationshipping’.
I’ve never understood how these 3 departments, whose alignment is critical to shipping great digital products, don’t work closer. It feels like we should be closer, and spending time together as if we were the SAME department. Because we are.
Well there it is. 3 separate departments. That’s not very collaborative. Let me proffer this simple, yet powerful concept:
Lets build a new equitable relationship — behold the holy trinity:
Building the three pillars
Shipping great digital products is a tricky needle to thread. If you cant ship it, it’s just a bunch of JIRA, unnamed Figma layers and rectangles, diagrams and some code. Nobody is going to use it. The user does not understand ANY of this, they literally just update their apps or reload a webpage. If it’s usable and familiar, then they will engage. If not: cheque please!, and we are all updating our LinkedIn profiles.
A successful software release or update relies on three concepts being respected and adhered to:
- PRODUCT: You can’t come up with stuff that is difficult to design.
- DESIGN: You cant design stuff that is difficult to build.
- ENGINEERING: You cant build stuff that is difficult to ship.
Ship or die
Ok thats a bit harsh, but you are only as good as your last stable release
I’ve always been strongly against gatekeeping in product design, but the one thing I wont budge on is this:
*Product designer interview*
“What products have you designed that have actually shipped?”
Um…
Getting stuff out the door (stable release) is EVERYTHING. It show that you understand the end-to-end process, which means you understand the symbiosis between all of the disciplines, and the responsibility behind this.
Let’s be friends!
There is simply no reason why you cant be close professional buddies. Heck, every single thing you do makes the other parties look better. Product, design and engineering (PDE) need to really connect and bond. But how?
Empathy
It’s ironic how the bedrock of great user-centred design is also the foundation for creating a strong PDE bond (yup I’m still using that term)
Trying to put yourself in the shoes of the other person is one of the best things you can do to better your performance at work and heck, your career.
Those ‘other’ departments full of people? you NEED them, you need them so much, but you need to UNDERSTAND them. and to do that you need to visualise what it must be like to be them. This, like meditation, takes some practice, but once you try to immerse yourself with the professional lived experience of another human being in your companies pipeline, well that is a genuine moment.
Designers: in order to understand product, you need to spend time listening and engaging, discuss the roadmap, constraints, business needs and understand what it takes to be a great product owner, what their day looks like and how important their job is. Other than the user, they are your client. They wont push the button on anything unless they are 100%. And the engineers? they wont push any code unless its perfect.
Getting something cool out of Figma and into a customers hands is the real magic in product design. Everything looks cool in Dribbble or a portfolio mockup because it's virtual, it's not actually built in code. This is the part of design that is the most important. Getting stuff built.
Ask loads of questions
One of the best learnings I gained from leading high profile design projects was the value of asking a ton of simple, relevant questions. The more questions you ask, the more answers you get. And answers mean new information. High intelligence in humans is always identifiable by asking questions and being able to synthesise new information or data from the answers.
You cannot design a thing unless you understand the ‘why’. What problem are we solving here? what are the constraints, both technical, organisational, environmental and how do the business needs and future planning fit? what are we really doing here? are there any dependencies, what research or data do we need to start this process? And how do we quantify success? What are the metrics for this?
If only there was a document that could be used to formalise some of this. well there is, is called a ‘design brief’
A decent product team will make sure that there is a brief for each epic. A designer needs to make sure they have their questions answered, and that the answers satiate the questions.
Anything else? just ask. Ask as much as you like
If ever you are getting pushback for asking too many questions, then this is a red flag and should be seen as a blocker. Remember, in any relationship, communication is key.
Sharing is caring
Design is about many things, but sharing is caring. Share early and often. Don’t make a big bunch of stuff and then hand it over. This can lead to early disappointment, which leads to resentment. Make a few bits, rationalise them to the brief, business objectives and to the user needs or stories, then present to product and engineering fast and with a fidelity thats not too polished but not too sketchy. Take the feedback, drink some good coffee, revise, then get a sign off.
Developers are brilliant!
Designers and developers have a different brain. The design process is often difficult to practically justify or explain to anyone who isn’t creative. And unless you can write code, I mean like PROPERLY write production-ready, shippable code, then you need to understand it's a huge responsibility. One wrong line of code and the whole thing breaks, and they also have to deal with a ton of technical debt.
Give your engineer a virtual hug on Slack, that person is responsible for building your stuff, and wants to translate your designs into reality. Give them whatever they need. Be an ally, an advocate for amazing design but also a partner for production.
A note about quality assurance
Also it important to understand it’s not just the amount of time, effort or complexity for a developer to build your amazing creation. It’s also the time to QA and test it. If it gets left out of sprint planning or moved down the backlog, be cool and understand it’s NOT just code. It’s manual and automated testing too. Most products will support a multiple of devices and codebases, as well as regression testing (eurgh)
Again, liaise any empathise with a day in the life of QA. If your stuff gets descoped or left out of sprint, its fine to respectfully challenge, but its nothing personal
The crispiness
The fit and finish of any design, which lately I have referred to as the ‘crispiness’, relies on really great chemistry between designers and developers.
I’ve never understood why design and dev clash, other than a difference of cognitive types, from a design standpoint you want your stuff to pop, and from a development standpoint, you want your stuff to pop.
Remember, the user will only see the crispiness and feel the usability. They don't see under the hood. Everyone has a vested interest in the product looking tight.
Handover of your design needs to be perfect. I’m not talking about naming your layers, but creating an intuitive rationale behind everything from spacing rhythm to type sizes, and providing every single variable, in a fully working prototype, with full documentation as well as practical examples of any motion design.
Retro
Team retros are like relationship counselling, a forum to kindly discuss what we did well, what we can do better, and ideate some actions for improvement, all without blame or negativity.
Just look at Atlassian's guidance for retros:
- Don’t make it personal, don’t take it personally
- Listen with an open mind
- Everyone’s experience is valid
- Set the time period you’re discussing (last sprint, last quarter, entire project, etc.)
- Focus on improvement, rather than placing blame
This is essentially how any healthy relationship should conduct itself, particularly if there are issues or pain points. A time-boxed, calm and respectful retrospective, with clear actionable suggestions, agreed as a team. If only Agile did marriage guidance counselling…
Outro
Creating strong and equitable relationships between the trinity of Design > Product > Engineering is not spending all day in JIRA, meetings, or sliding into Figma together. It’s understanding each other and knowing when to dip in and to dip out. It’s mutual respect for each discipline and promoting healthy overlap but also delineating respectfully. It’s a top skill that takes years to learn, and it’s the key to shipping great products.
Product design is about relationships, get the chemistry right and releasing great products IS the product.
Thanks for reading!
Mx
p.s. If you like this sort of thing I also write about other stuff on my Substack
