It's received wisdom that the developer just needs to understand how the design works, and implement it without changing it. But how many times does the developer start coding the design, and notice something that wasn't anticipated by the design? We find that it's quite often. Our developers specialize in Ruby, Elixir, Angular, React and other frameworks. The developer is the first person who actually sees the system doing (or trying to do) what the user needs it to do. What kinds of observations do we harvest while they’re in the throes of writing the code?

Response times. Time to load the page. Time to load the data. In the end, the delivery platform will influence the time it takes to load the page. But the developer is the first one who can actually see what is being delivered and estimate what the user experience will be in production. When the developer identifies a gap, they ask the product owner or designer for a new story, for a waiting state. Once the design is done, the developer can gang the original ‘view’ story together with the ‘waiting state’ story, and release a working feature instead of a broken one.

Dirty data. Developers often see data that was not anticipated in design. V-e-e-r-r-r-y-y L-o-o-n-n-n-g-g data. Data in different languages. Data that looks like gibberish and needs to be translated for users to understand. Old data that needs to be filtered out of the results because it doesn’t have an interpretation in the current design. The developer who finds this asks for a story to handle the unanticipated case, and adds the appropriate dependency to the current story.

Short cuts. Sshhh! This isn’t really supposed to happen. But when it does, you can’t ignore the savings. Sometimes a developer discovers that a complex case that was designed actually has a very small chance of happening, and can propose a shortcut to handle that small number of cases manually, or not at all. The result could be a much simpler, more intuitive interface for everyone.

Business logic bombs. Product owners and designers think pretty hard about how to strike a balance between the value that a user gets out of software and the way the business gets paid to provide that value. But even then, a developer can find loopholes and workarounds in business logic that need to be addressed in order not to leak revenue right out of the gate. 

Extra domain knowledge. Sometimes, developers may represent some of your design personas better than anybody else on the team. Not to put too fine a point on it, but some products are targeted at very precise thinkers. When a developer is bothered by the way something works, they initiate a conversation with a designer and let them know directly.

Web developers make everything just as hard as it has to be, and no harder. There are times when a developer makes an observation that is at odds with the desired design aesthetic or a business objective. And they’re not always representative of the users you’re trying to serve. But if you ignore the feedback of the very first users of your product (the developers who code it), how likely is it that you’ll listen to the feedback of the next hundred? The next million?

At Lab Zero, we tune in to the signal from all of our users, and our very first users often have some pretty good feedback.