Let Developers Be Developers
When organizations expect developers to do and be everything (content strategists, information architects, user researchers, and designers), it shows.
Developers Can’t Do It All
Yes, developers are singularly amazing and critical to your digital product. They perform highly specialized tasks and provide essential expert input. But they can also be forced to wear many hats—and not all of those hats fit correctly. Developers often wind up doing all sorts of non-dev tasks: writing all words (help text, error messages, etc.) in a product, laying out apps visually, or making software easy to use. Sure, the products they create function as expected. But when they are asked to move beyond their core competency, they create interfaces that are, more often than not, unusable, unhelpful, and mildly reminiscent of Frankenstein’s monster.
That is because developers are developers. They are not content strategists—so don’t expect them to write intelligible error messages. They are not information architects—so don’t hope for an intuitive, human-understandable structure. They are not visual designers—so don’t be surprised when the product looks hideous. And above all, most developers are not user researchers—so if you foist an entire project on their shoulders alone, don’t hold your breath for excellent user experience.
As with any other individual in any other discipline, companies cannot expect developers to produce high-quality work in areas they do not specialize in. When companies expect them to miraculously multitask, they force developers to steal time away from the things they excel at and waste time on tasks they aren’t well-equipped for. That makes for subpar work across the board.
Maybe you’ve seen the evidence yourself. Here’s what can happen when digital products are fully dev-driven.
Classic developer-written error message with bonus attempt at graphic design.
This is what happens when you give a developer a list of links to add to a page.
Go ahead. Try to decipher this.
So. Many. Instructions.
Four Examples Among Thousands More
These cases typify what developers come up with when they are forced to wear many hats. They exemplify why developers shouldn’t build digital products without broader support, no matter how talented those developers are.
If the examples above seem close to home, your team needs to grow. Otherwise, your organization will continue to expect too much as your developers continue to underwhelm in areas they don’t specialize in.
Redefining “Development Team”
Here’s what a larger, more balanced project team would bring to each of these screens:
· User Research: An immediate dive into the use cases that inform these products. Who uses this product? How, where, and how often? To get this, you need a user researcher.
· Information Architecture: A strong, top-level navigation that will do content wonders—and make it easy for users to understand structure. To get this, hire an information architect.
· Content Strategy: A meticulous look at content priority and interaction. What information is most important to these users? What do they need to get done? To get this, bring on a content strategist.
· Visual Design: Careful thought about tone, layout, and interaction. And an end to the visual chaos. To get this, you need a visual designer.
Expanding Your Team
Now, it’s easy to say, “Get a bigger team.” But that doesn’t account for the budget and approval limitations teams operate under. But you can make progress. If you want to forge a more holistic digital product team, you must show how much your product lacks without it. The best way to do that is with a user test, which can give you the firepower to achieve that thumbs-up to expand your team.
Observe how users interact with your digital product (or fail to interact with it). Invite the dev team and leadership to watch. Odds are the results will be sobering for developers (who may not realize the depth of the usability issues) and informative for decision-makers (who know the digital product needs improvement but might not know how to accomplish that). Remember—developers are not user researchers, so don’t ask them to tackle this step. Outsourcing is a viable option at this stage.
Once you’ve gained traction, push to hire the right UX professional based on your current team’s makeup and upcoming project needs. Or, if your organization’s decision-makers are not willing to expand your internal team quite yet, consider augmenting your crew with an external UX team to bolster your efforts immediately.
The point is you have to try. If you do nothing, your team will continue to make the same mistakes.
Relieve Your Developers
In most cases, developers forced to wear multiple hats know that they are poor substitutes for UX, content, and design professionals—and they WANT the help of these folks. They are doing their best with limited time and a limited range of skills. And that means your digital product (and your company) are bound to suffer.
Expanding your team with the right individuals can be the fertilizer that makes your site or app flourish. That takes an honest assessment of your team, what your team produces, and your company’s own willingness to grow.
Our team has been doing the real work of user experience since the earliest days of the commercial web. We’re out to make your digital products a whole lot better.