If you’re an engineer who works on UI, it's your duty to implement the vision of designers and product managers to the best of your ability. At the same time, you're not merely a cog in the machine: You're a technical subject-matter expert with nuanced thoughts and ideas — who knows best what it takes to get designs actually built.

That means your role is more than simply charging forward with a solution to every feature that's assigned. Sometimes, it makes sense to say no — or at least offer insights and options that allow the product team to make more strategic decisions.

Here's when it makes sense to push back, and in doing so, distinguish yourself as the kind of engineer product can rely on as a partner in the generation of business value.

Business value is everything

Every business wants to generate value and make money. I mean that in the least cynical way possible. The structure of business is simply such that value is generated in a coordinated fashion, and money is simply a tool for measuring that value.

Critical to generating value is allocating resources strategically. Every hour you as an engineer spend on some task deducts not only from the overall pool of funds, but from the weeks and months remaining in your timeline. If you're a startup with a limited runway, that could make or break your company. But even if you're a large organization, constraints like being the first to market can make or break entire products.

As such, product managers are incentivized to allocate resources in such a way that maximum possible business value is being generated at all times. And in order to do that, they need to understand their options.

The business requires your perspective

That's where you come in. As an engineer, you understand precisely what's involved in implementing the user experiences created by the designers and product folks you work with. Sure, some members of product might have a technical background, but there's still a certain kind of direct insight that you have into the details that only comes from working with the code day-to-day.

As such, if product has any hope of making informed decisions, you absolutely must share this insight. In other words, your job is not merely to offer estimates and push forward at all costs. Your job is to offer estimates, consider the implications of what's being asked, and offer alternative paths (at least on occasion) that might be more timely or generally better for the goals of the team.

Pixel perfect – not always perfect

Let's consider an example. Perhaps you work on a team that values pixel perfect implementations of the UI mockups that you receive from your designers. In fact, the rigor of being pixel perfect is a point of pride and any deviations are flagged as UI bugs to be addressed asap.

This may sound like a high-value policy, and that may be the case most of the time. But in some cases, you should absolutely deviate.

Once upon a time, I worked on such a team, and I was asked to correct such a UI bug. It was an iOS app where the buttons on either side of the navigation bar were meant to be exactly 20px from the edge of the screen.


The idea behind the requirement was reasonable. The designer wanted all the visual elements to align in such a way that the whitespace around the content felt consistent and natural. The problem was that he wanted to apply this rule not just to standard buttons, but to back arrows as well.


As you can see, the back arrow is actually a little closer to the edge of the screen than other buttons. And the text beside the arrow is also not particularly aligned with anything else, which this particular designer did not find acceptable.

However, the right decision here was not to change a thing. It was to push back, and explain the implications.

You see, at the time (and this may also be true now), it was kind of a pain to adjust the spacing of this particular kind of button. It's part of a standard UI component of the iOS SDK, and a detail for which Apple didn't exactly encourage customization.

Customizing it, therefore, introduced a whole lot of unexpected complexity and risk. For one, it took much longer to do than the designer anticipated. It wasn't merely adjusting a setting, but rather implementing a whole work around that fought with the standards of the system. This change, further, needed to be made for all navigation bars in the app, and it introduced the possibility for unexpected behavior in certain circumstances where other layout code was at play. The feature, further, added testing time to the QA team, and in total it all added up to a not insignificant number of hours.

In other words, this could have been done. And it wasn't necessarily hard to do. But this is not something that we really need to be allocating hours for at all. It offered no business value, and in fact, perhaps negative value in that it diverged from the expected positioning of the back arrow that users see in almost every other app on their device. Why go through all the trouble?

Be a source of options

Now, you might be thinking it’s not your job to usurp the role of product manager and police the design requirements. You may not even feel like you have much to say about design at all and would rather just trust the design choices of the experts. And you'd be right for the most part. I pretty much agree.

But this is not about you making design choices. It's about double-checking that this choice is something the design experts actually want to make given additional data.

It’s likely they would never have expected something as simple as button spacing to be such a pain when they set the requirement to begin with, let alone the other forms of risk it introduces. So it’s valuable to inform them so whatever decision they make is based on the closest possible approximation of reality.

Likewise, there may be some other feature they'd like to squeeze into this release in lieu of the lower value item, or they might prefer to reduce the risk of extending the timeline to prioritize the more important features already allotted. It helps them make decisions that lead to more desirable product outcomes, and you are a partner in doing so when you give them options.

Present options agreeably and negotiably

Now, the way you present these options is also very important. The last thing you want is to be seen as an engineer who “doesn’t get design” and who is just being difficult.

To avoid this, you need to avoid the trope of the engineer who says: “No. X can’t be done for technical reasons. You wouldn’t understand.” And in order to avoid that trope, you simply present the info in a way that any non-technical person would understand with ease.

This is a lot less complicated than it seems. Turns out, a designer or product manager doesn’t actually need to understand the technical details in order to reconsider their requirements. They just need to understand the pros and cons in terms of what matters to them: user experience and business value.

And to frame the problem this way, try reframing it through one or more of the following lenses:

  1. Implementation cost: An engineer’s time is expensive, even if you’re a junior engineer. In the spacing example above, it’s highly unlikely that the designer or PM actually anticipated such a high cost for such a simple requirement. Explaining to them that this little thing actually introduces X hours of dev time (when it was expected to be no more than a few minutes) might be all they need to hear to let it go.
  2. Testing cost: In addition to engineering cost, every requirement adds to the hours spent by the QA team to ensure the experience meets the products standards. This spacing tweak doesn’t simply affect one feature, but all screens across the entire app, which means additional steps during regression testing. Are they worth it? Give product the data to decide by being clear about those steps compared to what is currently involved.
  3. UX risk: When you introduce requirements that fight the system, like this spacing tweak, it introduces the possibility for all kinds of wonky behavior that may only appear in unexpected circumstances. Perhaps the way you implement the spacing causes the button to be totally out of position when a navigation controller is a child of some other view controller, for example. Make a list of possible ways such a change might lead to other problems that may in turn cheapen or disrupt the UX elsewhere in the app and subsequently cost even more to fix later.
  4. Delivery risk: Likewise, any added complexity adds to the risk that a feature might not be delivered in time. If you’re spending way more time than anticipated on enough little things, the time and bandwidth to complete what matters gets eaten up, and teams fall behind. Explain the degree to which this kind of risk might manifest, and let product decide whether it matters to them.

Notice how none of the above involve a non-technical person understanding the technical details of why something is complicated or risky. Rather the focus is on quantifying the ways in which it is risky and clarifying qualitative implications of such risk. All the while, data is being presented as a basis for the design and product experts to exercise their expertise rather than the engineer simply dismissing the requirements on technical grounds.

And by the way, this process applies for design elements and features both big and small. Whether a UI choice could add a few hours or a whole extra sprint to a project, it’s important for engineers to be able to communicate the work associated so that product teams can make the right production call.

Balance feedback with company culture

Every company is of course different. Some welcome and encourage this sort of feedback from their developers, while others have different attitudes. It's also possible that your feedback might be initially misunderstood as design criticism, and there's always the issue of sensitive egos. Any feedback you give should take into consideration the culture of the company you work within and the individuals you work with.

That said, if you're in an environment that welcomes cross-functional collaboration, and encourages candor, feedback of this kind can be invaluable to a team's success. By providing it, you're giving your team an added layer of transparency and clarity into the realities of implementation, encouraging the best possible outcomes. And it could really distinguish you from other engineers as a team player who's really oriented around outcomes so long as the feedback is delivered thoughtfully and constructively.


Share Article

Continue Reading