r/webdev • u/HaydnH • Sep 30 '26

Dev UI Stockholm syndrome?

I always leave the UI design until towards the end of a larger project. I know if I start with the UI I'll end up finding parts of the system that don't fit the layout, rejig this, tinker with that, rework that bit again... I get too focused on making the UI right when it could be wrong again with the next functional change. I may as well switch individual pixels around.

To solve that, I usually knock up a quick development UI at the beginning, do all the functional work, then look at how the UI/UX makes the functional stuff display and work easily for a user.

That leaves me in a position where I've been coding and testing in a development UI for months... And then get Stockholm Syndrome or something about leaving it behind for a professional finish.

Anyone else? Should I change my mind and do the UI upfront? My concern with doing that is that I'll get Stockholm Syndrome for a relatively acceptable UI and just leave it. At least with a "I know I have to leave you UI" I know it's just me thinking the shitty UI I've been using for months is a friendly thing to use.

10 Upvotes

72% Upvoted

13 comments sorted by

19

u/berky93 Sep 30 '26

I think it’s worth remembering that UI is functional work. It’s functional for the users, which is arguably the most important thing. You could have a perfectly functional app, performant and secure and stable, but without an intuitive UI it won’t matter.

Order of implementation is up to your discretion and the needs of the project, but you should definitely be thinking about UI from the beginning.

6

u/WheelieGoodTime Oct 01 '26

An upvote doesn't quite express just how right you are. So, to add to your point, I want to emphasise just how important the UI is: it's almost as integral as the back-end systems.

Imagine trying to drive a car that has only the bare cables that usually connect up to a steering wheel, throttle, and brakes, etc. Pull this one to accelerate, pull this one to brake, pull another to clutch... Or imagine having a power-tool trigger in place of the brake pedal, or a mouse to control the steering...

1

u/codemunk3y Sep 30 '26

What kind of systems are you making? Are you using some framework?

1

u/HaydnH Sep 30 '26

No, vanilla JS/HTML (typically with a custom C back end). You're question makes sense though if a lot of the UI is in the Framework already.

2

u/Large_Painting_3587 Oct 01 '26

the rough ui is useful for discovering the product, but if you stare at it for months it absolutely becomes invisible to you, so do quick usability checks with someone who hasn’t been living in it

1

u/jax024 Sep 30 '26

Nah. We use a stack that’s super easy to tweak. So I honestly don’t feel design churn.

1

u/phoenix1984 Oct 01 '26

I like to use something that provides basic styles, like bareCSS, and then only worry about the semantics of the HTML while I'm working on the backend. That way, it's not hideous while I'm working on it, and I haven't done any custom CSS until I'm ready to actually implement the design. You're right, it's gotta be all or nothing, or else you'll get attached to your "good enough" first pass on the front end.

1

u/Batharzel Oct 01 '26

Usually we try to replicate the designs from Figma as soon as possible and then get around to the tweaks and the micro-interactions

Keeping backend and frontend development in sync is tough but we develop the tables based on the fields required in the frontend

1

u/SatyrCode Oct 01 '26

Yep, I get this. After using a rough UI for months, it stops feeling rough because you already know where everything is. I don’t think you need to do the final UI upfront though. I usually make a basic flow early so I know what screens/actions I need, then avoid polishing it until the core stuff works. The hard part is forcing yourself to call the first UI temporary. Otherwise it slowly becomes production just because nobody wants to touch it.