it doesn't matter even if your code cures cancer. it's always the ui that matters

So what's preventing me from launching my startup/service/platform to the public? Not ready to deal with users like Nancy.

Product and Design have a common enemy. Yes, you guessed it right, Engineering.

The former aim to solve user problems and focus heavily on aesthetics most of the time. While the latter actually does it.

As a Product guy, I admit that I absolutely hate the role these days because all that are asked to focus on is engagement retention conversion and other fancy metrics. Community has missed the entire point of why the fucking role exist.

On the other hand, engineering always asks the best questions. Focuses on performance and scale while periodically checking on tech debt. Yes, they suck at business or sales but when the solution works, things automatically make money.

I DON'T FUCKING CARE HOW BEAUTIFUL YOUR APP IS, IF IT DOESN'T SOLVE MY PROBLEM THEN IT'S RUBBISH.

Functionality and UX matters to more than colour scheme or fonts. Reason why Amazon is a huge. They are functionally solving a great problem while constantly improvising UX and not giving a rat's ass on UI.

Another down side to your fancy design is that the UI elements make things heavier. No wonder engineers have always been the best problem solver.

We lost our way. Tech world needs to go back a decade or two to fix the tech debt.

Pulled into an 'emergency' meeting with a group of web designers deeply concerned a particular service wasn't going to meet all their requirements.
DevA: "For each page, Its going to be A LOT of work to retrieve all the data and store it's state. Every page load will require a round trip to the service."
DevB: "Yes, we aren't sure how the service should be changed to do what we need."
Mgr: "What is it not doing now? Doesn't the service already returns all the necessary data?"
DevA: "Well...um...its all the boolean fields. Some may be defaulted from the database or false because the user unchecked the box. We have to know which is which"
Me: "Why? Are you doing anything different in the UI? Checkbox will be true or false. What or who set that value is irrelevant"
DevC: "Well, it matters if the user didn't fill out all other other values."
Me: "How so?"
DevA: "Its matters because the values in the other fields. Its going to be A TON of work to figure out."
<mgr goes to the white board>
Mgr: "Lets map this out...what fields are you needing to trigger the state on?"
DevA: "Um...uh...the 'Approved' field...and um...'OK to Contact' field"
Mgr: "Just those two?"
DevA: "Yea..um...there are other fields, but whether or not to show the edit box depends on those two."
Me: "The service already returns data, you only have two fields to check? I don't see a need to change the service at all."
DevA: "Returning all that data, we are going have a serious scaling problem. We'll be hitting the service A LOT. All that javascript could cause performance problems too"
Me: "How much data are we talking about? Name, address, couple of booleans?"
DevA: "I have to serialize the data. All that logic is going to be reeeaaallly complicated. It might be better if the service returned only the data I need."
Me: "$64,000 question, how often is this feature going to be used on the web site? Maybe once? Few hundred a week?"
Mgr: "We have no idea. A lot of the data will be pre-populated and we're only sending out a few thousand invitations. More around the holidays...but honestly, not very many."
Me: "Changing that service only for this particular area of the web site isn't going to happen. Changing the UI is the only course of action."
DevA: "Oh frack I can't wait until this project is over."

DevA...how the funck do still have a job here? You wasted about half-hour of my time with your cry-baby crap. Where is my hammer...no...no..don't go there...ahhh...thanks devrant. Prison sentence diverted.