The ultimate test of a design is always going to be in the hands of the users. It isn’t possible to exactly predict how a piece of software will be used. But along the way, there may be signs that a design is lacking in some way. One such sign is when the cost of implementation doesn’t seem to be justified. It is the role of the developer to recognise this situation as early as possible and provide feedback to an iterative design process.

Sunk Cost

For anyone unfamiliar with the notion of Sunk Cost and the psychological pitfalls that go along with it, picture this:

You have received a design for a piece of user-facing software. Everyone (you included) has agreed that the design both looks amazing and is the best way for the user to perform the myriad actions that the software will need to support. Work begins.

By day 44 you have tried 45 different libraries, custom implementations, workarounds, and “unorthodox approaches”, and by lunchtime, you’re almost positive that you’ll have the map screen working just right, along with the automatic zoom and pan animations. Sound familiar?

At this point, the idea of just giving up on that map screen would be utter anathema to any of us. We’ve simply invested too much. To throw it all away now would be madness. What’s more, it wouldn’t make sense for the business. It would be a waste. This is the sunk cost fallacy.

What if I told you

What if I told you that, by version 1.2, no one will be using the map screen? When the software is given to users, it will be found that a simple list view with a search bar is much more useable. The map screen is moved off to a secondary page and can still be accessed obliquely from the now first-class list view. But no one does.

So what went wrong? At what point would it have been better to push back on the design? And for what reasons?

The answer, of course, is “Early, often, and continuously”, but that’s a lot simpler to say than to do. As developers, we know that our job is to make it so, and of course, this is true to an extent. When something non-standard is requested, our first response certainly should not be to shoot it down as too difficult, or not possible. Who doesn’t love a challenge? And isn’t everything possible?

While it’s not a good idea to become the naysayer in the discussion, it is absolutely our role to point out when things will be technically difficult to achieve. We may not always be able to recognise this at the outset, but once we’ve sunk our teeth into a problem, it doesn’t take long for us to get a sense of the landscape (by day 44, the writing is on the wall).

At this point, it is in no way a defeatist attitude to point out where something non-standard in the design may be more difficult than expected, or even not possible within the timeframe. It’s time to weigh things up. It’s time, folks, for a table!

Time for a table

As the title suggests, we need to be able to recognise when to question the UX. Signing off on the designs should not be equivalent to agreeing on what will be delivered. It should instead represent the initial best-guess by all parties on what will be the best way to provide users with the required features. Like most humans, the designer will not always get it right on the first go, so an iterative approach is only logical.

But when do we decide to question or push back on the design? We know what our role is, we’re the developers, not the designers. We’re sensitive to the fact that we’re not the expert in the room when it comes to the UX. However, we do have a horse in the race, so we ask ourselves: Is this a good way to provide the feature to users? Will it be technically straightforward and easy to achieve? Can I suggest a different or better approach?

To highlight the now neatly tabulated point: At times, it may be worth questioning the design if we think it could be improved, whether or not we have a suggestion on how to improve it. But it is always worth questioning the design when its implementation is going to add unnecessary cost, even where we may agree with the design approach.

The result may not always be a change in design. There will be times when a revision of the requirements and the proposed UX reaffirms the initial approach, and there’s nothing else to be done except to meet the technical challenge. There will also be times where a well-placed suggestion can save countless hours of wasted effort. What is important is that we as developers are providing an analysis of the associated costs as an input to the decision-making process and that we do this as early as possible.

So what’s the verdict

The cost-to-implement is a relevant and valuable input to the design process. It is our role as developers to provide this input. The cost will often only become apparent after work has begun, so it is important that this not be considered too late, the initial design should not be treated as gospel (by anyone).

As developers, we need to be careful not to keep hammering away at an implementation. Avoid the sunk cost fallacy, and avoid becoming attached to a particular design approach. Always focus on the user.

When is the time to question the UX?

Now.