Why developers need to challenge product and design
Rare is the developer who hasn’t had to “throw away” their code. For many, discarding months of hard work has been a common, recurring theme of their career.
This is how it happens: someone in management thinks they’ve identified a problem. They rally a bunch of people together — product owners and maybe a few designers — and collaboratively hash out a solution to the apparent problem.
Once all the decisions are made, and the solution is ready, a development team is assembled and they’re handed the product requirements. “Build this,” they’re told.
This is where the two different types of developers reveal themselves.
Consider the first type of developer: the complacent.
When presented with a set of requirements, the complacent developer gets straight to work without any fuss. They’ll ask questions to fully understand the requirements and debate the best technical architecture to implement them. But once that’s worked out, they’ll knuckle down for a while, emerging only once they’ve completed a system that not only matches the given requirements, but does so with clean, fully-tested and robust code.
Sounds perfect, right? There’s just one problem. Those requirements that they’ve meticulously implemented often fail to actually match the user’s needs.
Though the implementation may have been executed with the utmost proficiency, the developer may as well have been writing code for eskimos. That is to say, it won’t see the light of day because the fundamental requirements failed to cater to the actual user needs.
Thus, we begin to see the value of the second type of developer: the challenger.
Like the former, the challenger asks questions to come to an understanding of the requirements. But, their line of inquiry doesn’t stop there.
Once they understand what’s being asked of them, they challenge it: Why are we doing this? How does this benefit the user? Where did this decision come from?
The challenger refuses to take on work that they know doesn’t fit the user needs, and they’ll more often than not take it upon themselves to propose alternative solutions. Even if they don’t propose a solution, the simple act of challenging a decision can spur the product team to think about aspects of their solution that they hadn’t previously considered.
In other words, the challenger doesn’t need to be a “designer” in order to improve the design. As with recovering from addiction, an awareness of a design flaw is the first step in creating a product that works for the user. More often than not, these flaws are easily rectified. But, a design flaw can’t be resolved if the designer doesn’t realise it exists.
It’s also not always the case that the “complacent” developer isn’t aware of the potential flaws in the solution they’re building. Often, they are. But, for whatever reason, they refuse to speak up, and may even moan among fellow developers about the oh-so-obvious flaws in the product that they’re building.
This is often because the design and product teams have historically refused to give the development team a platform to propose feedback or changes. Routinely ignoring a developer’s suggestions is possibly the most expedient route to converting a keen challenger into a complacent developer.
So, while to an extent it is up to the developer as to whether they challenge a solution or fall complacent, the rest of the team need to make sure that the developer has a platform to speak, and will have their voices heard if they utilise that platform.
As Donald A. Norman, director of The Design Lab at University of California explains, “all things artificial are designed.” In that sense, anyone involved in building anything is a designer to some extent. Design isn’t just about building user interfaces or crafting interactions, it’s about creating an experience. It’s about understanding that the user is a human, and understanding all the nuances about being a human.
In that vein, anyone with a shred of empathy or even a vague understanding of human emotions will have something valuable to contribute to the design of any product.
By adhering strictly to job titles and shoe-horning people into silos — in other words, artificially prohibiting a developer from design — you only serve to cut your team off from valuable insight and resource.
Everyone wants to build something good. Nobody wants to finish the day at work acutely aware that all their efforts have contributed to a product that ultimately won’t see the light of day. But, no-one (well, most people, at least) wants to sit all day without anything to do.
That raises another thing to consider: wasted resource. It’s a simple fact of software development that there isn’t always development work to do. Sometimes, the team need to take a step back from development and reconsider the design, do more research, or consider the next steps on the roadmap.
But, in these hiatuses, how should developers utilise their time?
In my experience, developers are doled out busy-work or told to develop future features that haven’t yet been fully tested with users — that is to say, the requirements will change. When those requirements do invariably change, the development work is then re-done.
Yes, this approach keeps developers busy. But, is that really the best use of their time? I don’t think so. This problem is especially prevalent in government, when that time is paid for by the tax-payer.
A better approach? Recognise that even though their job title may read “Software Engineer,” “Frontend Developer” or “Dev Ops Engineer,” they have value as designers.
If you’re involved in product, include the development team in design. If you’re a developer, make sure your voice is heard. If there’s a flaw in your product’s design, let the team know. It doesn’t matter what your job title is.
A final word of advice to the “challengers” out there: while I advocate challenging the work of designers and product owners on your team, you must also respect that, just like your users, your colleagues are human. They also want to do the best work they can.
“When we are wrong, we may admit it to ourselves,” explains Dale Carnegie, author of “How to Win Friends and Influence People. “And if we are handled gently and tactfully, we may admit it to others and even take pride in our frankness and broadmindedness. But not if someone else is trying to ram the unpalatable fact down our oesophagus.”
In other words, if you make someone feel like they’re wrong, it’ll only make challenging their work even harder. Treat them “gently and tactfully,” on the other hand, and you may just be able to change their mind.Adam McKenna is currently a Frontend developer at DWP Digital. Find out more about what the organisation does on their careers site.
December 2020
January 2018