Carpenters shouldn't do plumbing like programmers shouldn't make user interfaces

Picture the scene: you’re planning a new house in the middle of a lovely green field. You get the architect to design it, the builder builds it. Each skill is equally respected for the value it adds. You wouldn’t get a carpenter to do the plumber’s job or you’d end up with wooden pipes.

This is almost offensively obvious. But all too often, digital development projects ask one discipline to cover for another. When developers are left to build the user interface (UX or user experience), the results are particularly telling.

At Fluent, we know how to spot the tell-tale signs of projects where developers aren’t playing to their strengths. If you recognise them in your own work, it might be time to pump the brakes.

UX vs development: What’s different?

Development is about what users need in order to do something. UX design is about how they go about that task. The mindset needed for each job is radically different from the other:

• UX designers care about how things are used, not only the logical end result
• Developers focus on solving problems to create the desired outcome

Going back to our house, the UX designer is the architect and the developer is the builder. The architect envisions the finished house, how people will live in it and move through it. The builder constructs something that won’t leak or fall down.

When developers do UX, it’s not that they choose to make clunky, messy interfaces. It happens because someone asked the carpenter to do the plumbing. Good developers know their own limits. Good project managers know not to ask devs to overextend their skillset.

Five signs that your project needs more UX love

It’s easy to spot the end result of someone who isn’t a UX designer doing UX design: an ugly interface is hard to argue with. But what do these projects look like midway, when the possibility of saving them from UI Hell still exists?

1: The user journey plays second fiddle to the database

Your alarm bells should start ringing if there’s little to no mention of UX at all in a project’s early stages. It needs to be baked in from the beginning, not used as icing at the very end.

If the navigation is just a 1:1 map of the database instead of something built around the user journey, you’re in trouble. There’s going to be no flow and no real insight into what people intend to do at each stage.

Focus will be on developers doing what they do best: getting something built which functions. This way, the likelihood of you needing to build a second version with a better interface further down the line increases. If you pay attention to UX from the start, you only have to build a product once.

Read how we helped non-profit org CAMFED increase donations through their platform by focussing on UX from the start of their rebuild project.

2: Your internal jargon is going bananas

Names have power, properly labelling elements of the project isn’t something you can kick down the road for later. Projects with no UX input typically go with whatever names get used internally. These names then leak into the interface despite being meaningless to the end user.

Even if you manage to avoid the bitter taste of acronym soup, improper naming makes scaling a pain. Example: if your business evolves from a subscriber-based model to one supporting one-off purchases, you don’t want a system that calls every customer a subscriber.

Read how mapping User Journeys on a client project helped avoid internal jargon going public

Tiny differences in connotation between words like customer, user, subscriber or member can make a huge difference to usability. It’s a great idea to include a product manager in your early discussions. They’ll know where the product might be heading in future and advise on naming conventions which support that growth.

3: All of the options all of the time forever

Think about where you’re putting all your user’s possible options. If the answer is just ‘on the screen,’ that’s a red flag. Pure development thinking tends to produce enormous, cluttered interfaces which can do anything the user wants.

Navigating such a behemoth, however, is bloody terrifying. It’s hard to keep things simple, but users appreciate it when you hide all the noise of things they don’t need to worry about.

Developers also love including instructions for users to read. Because that’s helpful, right? Well… yeees. But intuition beats instruction every time. UX thinking aims to show not tell.  More iPhone-esque glee, less reading the manual.

A designer can get their head around what options someone needs to see at each stage of their journey. Everything else can be minimised or hidden entirely. Time spent onboarding new users gets cut dramatically so they can start using the product faster.

4: Things look all higgledy-piggledy

This one can be hard to spot because it takes a designer’s eye. Changes in styles, inconsistent use of whitespace, or a random colour palette all make for a disconcerting, inconsistent experience. If a project’s layout and appearance evolve solely in step with development, the look and feel are going to drift.

A designer will polish those tiny differences in layout and font that others don’t even notice. But even better, they’ll usually begin a project by recommending a design system to use from the start. These modular toolkits are flexible enough to do what your product needs them to do. They’re also structured enough to make everything feel like a part of the same coherent experience.

Read how we created a design system for Oracle Grapeshot to improve consistency of design across their digital product suite.

5: Your code is bloated

A project that’s led purely by a development mindset will reuse as much as possible from what worked in the past. That’s cool, but not always as efficient as you expect, and very rarely elegant.

To give maximum functionality, devs find themselves using an entire framework to support just one component, then adding another framework for one more component as the project evolves.

That’s a bit like having to subscribe to four different streaming services to watch your four favourite shows. It’ll work, but it’s inefficient and expensive. Designing the UX upfront and as a result using a single coherent framework can give you simplicity and keep costs down over the medium term.

The Fluent approach: UX and development are co-dependent

So, how do we do it? The way we make sure UX and development avoid stepping on each other’s toes starts with an honest appraisal of the project. Sometimes it’s not possible to paint over the cracks, it’s best to start over with the next version of a product using lessons learned from the current instance.

You might think a blank canvas would be our favourite start point, all that freedom to make our own choices and do things right. Actually, we prefer to start with a bit more structure and guidance. We love to see a pre-existing template or design system to help make multiple apps work consistently in a consistent language. It helps to know the hard and soft constraints around a project.

This consistency lets everyone’s efforts make the biggest possible impact. A product manager can use the template and apply their knowledge of the user to guide us. A developer can get on and build without interruptions. We can then help inform UX decisions that reflect what the user expects to see at any given time.

Different elements of a project working against one another makes no sense. A coherent view of process and journey, clearly understood, ensures projects go forward with a healthy, balanced mindset.

That’s why Fluent - with our blend of UX and development talents - are such a good fit for your project.