I have given this talk under a couple of titles. One of them is “UX for Devs: Making Software Pretty Useful.” The phrase is a play on words, and the play is the whole point.
For a long time, the most common reading I hear from developers is “make software pretty.” That is the one where UX means nicer buttons, better colors, and rounded corners. It makes UX sound like a coat of paint you apply after the real work is done. That is wrong.
There is a second reading: “make software useful.” Craigslist is the example I usually reach for. It is not pretty. It has probably never won a design award. But it is useful enough that people keep showing up. I have also seen software that looked gorgeous and died because nobody needed it. Pretty, but dead.
Put the two together and you get the reading that matters: make software pretty useful. That phrase works three ways. It can mean software that is useful enough to be called “pretty useful.” It can mean taking software that is already pretty and making it useful. Or it can mean building software that is pretty and useful at the same time. The point is not to trade one for the other. It is to do both.
This split points at two audiences this 8-part series will target. Some users show up with immediate pain. They will use ugly software if it relieves their pain. Other users do not feel the pain yet. They need something attractive enough to pull them in.
If the software is useful but ugly, the first group stays and the second group never shows up. If the software is pretty but useless, the second group tries it once and leaves. And once the first group’s pain is gone, even they start looking for something prettier that does the same job. Usefulness earns trust, aesthetics earns attention, and neither one can do the other’s job for long.
That leads to the central argument: messy UX almost always lives next to messy code. The two problems are the same problem.
In over thirty years of building software, I cannot remember a project where the user interface was a mess and the code behind it was pristine. It just does not happen. When the experience is confusing, cluttered, or full of dead ends, the code follows. There is no reason to keep the backend clean when the frontend is already a maze. The same duplication, the same special cases, and the same “we will sort it out later” thinking spread from one layer to the other.
The reverse is true. When the UX is clean and focused on what the user is actually trying to do, the code tends to become clean too. The paths through the system are fewer. The responsibilities line up from smaller functions to clearer names to better separation of concerns. The tests become easier to write, because the UI does not fight the test. I have watched teams give up on browser automation because the interface had too many moving parts. When the interface is concise, those same teams write the tests they always meant to write. Clean UX leads to clean code, easier tests, and happier users.
I have even worked with teams that sized user stories by the number of UI controls on the screen. Twenty text boxes meant the story was an eight. Fifty text boxes meant it was a twenty-one. That is a strange way to measure work, and it only makes sense when the interface is doing too much. Once the UI becomes simpler, the stories shrink, the tests become easier to reason about, and the code becomes easier to change.
That is not because pretty buttons make better code. Both good UX and good code come from one discipline: asking the right questions before you commit to an answer. The developer who asks “what is the user trying to accomplish here?” ends up with smaller functions, clearer names, and better separation of concerns. The developer who only asks “what framework should I use?” or “how do I save this to the database?” ends up with an interface that mirrors the schema and a user who has to learn the schema to get anything done.
Most teams do not have the luxury of handing this work to someone else. In all my years of consulting, I have worked on exactly one project that had a dedicated UX designer. The rest of the time, the design decisions fell to the developers.
That does not mean UX professionals are not valuable. It means the relationship should be collaborative, not sequential.The best results come when developers and UX designers treat each other as builders of one thing. In Scrum, that is the point: UX professionals are developers too, in the sense that we are all building the product. The wall between “design” and “development” is where useful ideas go to die.
When I say this is a developer’s job, I do not mean every developer should become a visual designer. I mean every developer should own the experience that their code creates. The backend rules that decide whether a button is enabled or disabled contain the reasons why. The frontend choices that hide or show information shape what the user understands. The language in labels and error messages already teaches the user how the business works. Those are all developer concerns, and they all show up in the UX.
The habits that make you write better code will make you build better UX. Start with the user’s task, not the database table. Name things after the business, not after the CRUD operation. Surface the rules that your if statements already know. Test the behavior the user cares about, from the first click to the final outcome. I have made this argument about code quality before in Why Code Quality Still Matters Even When AI Writes It, and about the back-end angle in User Experience Is Every Developer’s Responsibility.
UX is not a designer’s afterthought. It is the developer’s job, and it links directly to code quality. The same clean thinking that produces good code surfaces the right information to the right user at the right time. If the UX is messy, the code will be messy. If the UX is clean, the code can be clean. The user does not separate the two, and neither should we.
Leave a Reply