When I started out making software for freelance projects I would build everything "important" first (user auth, database requirements, basic UI), and then add the pretty UI at the end.
I noticed when showing off a project sans pretty UI I was met with some pretty disappointing responses. Once I switched to adding pretty UI at the beginning of a project the response was the opposite.
I guess there's something to be said about salesmanship somewhere in there. All I know is that if I kept focusing on what I thought was important first I probably wouldn't have been as successful as I was.
From a users point of view the UI is the software. To people who program for a living this may seem ridiculous: The UI doesn't do anything without the code. But to the user it's the opposite. The UI does the work, everything else doesn't even exist.
Exactly. The corollary is you demo a pretty UI with no backend and then have to watch the crushing disappointment when you say it can't be shipped tomorrow and you need another 6 months to build something behind it.
Ouch, yes. I have been on both sides of both situations, and it just underscores the true value of a good dev team, and management who understand the process, both internal and external. I would say the management is arguably more important than raw dev talent, as managing expectations is paramount to all other output in most business.
I can see why you did it that way. A lot of developers I know view those services, the plumping and foundation, as the exciting and challenging work. The pixel placement and moving just a hair left, no more left, is painstaking and what seems like highly opinionated to us.
The unfortunate bit is that because the UI is only what the customer sees your product will be judged mostly by that, especially on first impression. I have been on projects with what I can only describe as Rube Goldberg architecture succeed because of a pretty layer of paint over it. With that said without good architecture certain layers of paint are inaccessible.
With that in mind I now try to start projects at both ends now. Both with UI and Architecture and let both inform each other. This does slow me down as I context switch, but it allows me not to complicate architecture if the UI doesn't call for it and not complicate the UI if the architecture can't support it.
I've noticed in computer graphics and games that there are some simple things you can do that go a long way towards making the game "cool", things like particles for example.
I never thought something like this could actually save a dying project, I'll keep that in mind!
People normally call that making it "juicy". There's this awesome presentation on YouTube showing how a boring game can look awesome with some "juiciness", even if the core gameplay is unchanged:
I am almost ashamed to admit how many times I've reduced hugely complex things to what amounts to a demo on a shiny retina display ipad. The %99 percent of what-actually-solves-the-problem is still there, but most of reaction could be summed up with "oooh, shiny" :-)
I noticed when showing off a project sans pretty UI I was met with some pretty disappointing responses. Once I switched to adding pretty UI at the beginning of a project the response was the opposite.
I guess there's something to be said about salesmanship somewhere in there. All I know is that if I kept focusing on what I thought was important first I probably wouldn't have been as successful as I was.