View of a planet in outer space with a rocket flying past it. There are lines of code around the planet and in the flames of the rocket, representing rings or fumes.

Let Developers Be Developers

truematter
5 min readApr 11, 2022

--

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.

The Evidence

Maybe you’ve seen the evidence yourself. Here’s what can happen when digital products are fully dev-driven.

Exhibit A:

Classic developer-written error message with bonus attempt at graphic design.

An error message that says, An error has occurred while processing your request. Please try again or contact the support department and supply them below error code. The error code is 100. In red text, a message says, Error: Either client or user’s detail is invalid. Please contact system administrator.
Sorry, what? This error message might make sense to the developer, but non-technical users will have zero idea what to do next.

Exhibit B:

This is what happens when you give a developer a list of links to add to a page.

A series of lists. Each item in the list are blue to indicate they are links. The lists are not categorized well and the headings are varying colors.
All these links all function as expected. But there is no content prioritization, no sensical layout, and no visual design to speak of.

Exhibit C:

Go ahead. Try to decipher this.

A screen to verify individual tax income. There are two required fields. One of them has a yellow help message that says, Required. Format: L99999999.
Thank goodness there are links to FAQs and tutorials to “help” make sense of this baffling screen.

Exhibit D:

So. Many. Instructions.

View of a screen providing instructions. At the top of the screen is a red heading. On the page is varying instructions, including a space that has extra instructions in all caps.
Odds are, no one reads these instructions—instructions that wouldn’t even be necessary if the available actions were straightforward and intelligible.

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.

About truematter

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.

Author: @JessAndAmen
Graphic: @djosephmachado

--

--

truematter

Online experiences don’t have to be frustrating. We’re user experience experts making digital products useful, usable, and loved. #UX #UI #userexperience #web