I love working with designers. They teach me so much about the world by showing me so much that I have either ignored or taken for granted. And when you align with a designer’s vision of a product or the world, it’s really exciting to be able to bring them to life.
But quite often, we don’t have time. Usually, either the product manager, the business side or an external client will need things to be shipped sooner than you can complete it by. In this series of blog posts, I hope to explore times where I, as an engineer, had to negotiate with my product designer to find a middle ground to let us move faster. This classic tension between design and engineering isn’t necessarily just between colleagues, it could just be an internal struggle that you may be having with yourself if you’re working on a solo project.
Currently, I’m working on Parthean, a website that helps people become conversationally fluent in fields of their interest. We’re starting with a Design for Non-Designers community. Jason, who’s not only our Chief Design Officer, but also the community lead, sends emails out every weekday with a bite sized lesson that’s curated specifically for each user.
One important feature that we prototyped in our early days when we didn’t yet have a website was “shoutouts”. It’s a feature that is used most often by Peloton, where their instructors mention meaningful milestones that some of their students may have crossed in the middle of the workout, such as someone’s birthday, 50th, 100th, or even 800th class! It’s really motivating to have the instructor mention your name and accomplishment to the entire community, and our early tests showed that learners in our community really enjoyed being acknowledged publicly.
Jason mocked up what this would look like when a user lands on the page for the first time that day. This is what he had:
It looks simple, but let’s still break down the main components of this modal:
I estimated that these features would probably take me about two-three days to code up, taking into account Hofstadter's Law. But that would be a really long time for just one “small” feature, and we had plenty else on our plate. We wanted to get it done by the end of the day. And no, writing code faster or pulling an all nighter is not a viable long term solution if you want to survive the marathon of startup life.
I’ve learned that because we’re a consumer product, we cannot deliver a buggy user experience. Users have a high bar. They won’t know much or lament about the features they don’t see, but they’ll definitely be annoyed by something that’s poorly implemented. The founders all knew this, so we knew better than to attempt to implement all the features poorly. We were going to have to choose to cull some part of it.
Before continuing, I’d like to pause and acknowledge the pain of product designers all over. Stripping down a wonderfully conceived feature is difficult to do. At best, it’s sad for them to see only a reduced version of the product be put in front of users, and at worst, it’s offensive when we do it without their inputs and just make the calls. A big way I mitigate this is to always engage them when deciding on what to remove, even if they wince. Another way is by promising that the remaining features will come back into picture at a future date once we get signal from users that the shoutouts feature is something they love. Being user centric is core to the identity of designers, so that’s usually a place where we can find common ground. Just be sure to mean it when you say that you’ll work on it if users demonstrate that they do like the feature; nothing is more annoying than a hypocritical engineer or product manager.
Deciding which features to drop is where the negotiation begins. You probably have ideas of your own based on the specs listed above. I started by thinking about what would probably need a disproportionate amount of engineering time to get right.
I felt that the banner image on the top of the screen would take up quite some time to get right. If we wanted to put in a static image, it’d quickly become outdated and only last for 24 hours at best. Instead, we’d need to dynamically overlay the day of the week based on the user's timezone, but that introduces other inconsistencies. But from my previous experiences, I know it’s very easy to introduce time zone errors and even harder to debug them. If we remove the day of the week, then we’d be able to let Jason upload the image, and it’d still be relevant no matter when the user comes around to seeing the shoutouts.
But hang on. Before we continue down this rabbit hole, let’s take a step back. If we’re just trying to figure out if they will enjoy seeing their name mentioned to the rest of the community, did we need to go through the effort of figuring out the images on a daily basis with different quotes? Removing this would save me all the effort of figuring out how to overlay a quote of the day on top of an image, accommodate for different quote lengths, and to figure out what color the text should be so that it’s visible on top of the image when the image may have different primary colors.
So let’s take stock. This is where we’re at.
With that, we were at an MVP now. This is what it looks like on our website right now:
Does it spark joy? Not entirely. But that doesn’t mean we throw it out! We managed to put something in front of the users in about a day, and are starting to collect feedback on it. The feedback from users is a topic for another blog post, though.
Negotiating with product designers is not as difficult as some make it out to be. I’ve outlined some strategies above, such as helping quantify the amount of time that each specific part would take, brainstorming alternatives collectively, and anchoring against the user.
When talking to designers, two common frustrations I hear from them is that engineers either don’t respect their work, or engineers don’t understand where they’re coming from. In short, they’re asking for us to empathise with them. For me, that’s come from learning about the basics of design. Not only has it been humbling to realise how difficult it actually is, and taught me that design is so much more than just “making things look pretty”, it’s also helped me better communicate with designers because I understand where they’re coming from. I’m only just getting started in my learning journey and I invite you to take the plunge too.
Thanks for reading! If you've read this far, I hope that you found it useful. I'd really appreciate if you'd share with your friends and colleagues. This was my first blog post and a beast to write.
For more design tips, case studies, and principles, join our community!