This post will be about a topic that tends to be pretty divisive: is UI (user interface, aka the design of an app) important? Or how important it is? How much effort needs to be put into it?
In the startup world, where resources are scarce and you have to prioritize ruthlessly, choosing to spend time on polishing the UI can be detrimental for the whole app, since the resources used for that could be invested in something else, such as bugfixing some things that are annoying some customers or a new features which will increase the value your product is offering.
In my mind, the answer is pretty simple and dissapointing: it depends. Because UI is not a singular thing, but a whole category of things. It can mean various things, from the layout of the page which is critical for the success and clarity of an area of the app to the shadows of the buttons which are not that important and if one button is shadowed differently than the rest, it won't cause clients to ignore you, as long as you provide them value.
So, why did I want to write about a question if the only answer I can give it is "it depends"? Because I want to give you a small mental framework about how you decide if something UI related is worth doing now, or it is for later, or even better: not something that will require our attention for a very long time as its impact is so small that the probability somthing will notice it is very small.
So, now the good part: how do I prioritize UI work?
The mental framework I use is actually pretty simple: I don't think in terms of UI, but in terms of UX. The user experience is the ultimate goal: we want the users to be able to use our app without help, to be able to navigate and discover features without having to rely on external guides or even worse: customer support.
So, for each page/component/feature, I answer myself (and if I can't answer them myself I pull other people who have the proper context in the conversation as well):
By going through this questionaire, we often get our answers and we make an idea of how important a certain thing is to build. If we decide something is needed here and now, we go to the next phase: figuring out the effort requirements and decide what we do next, with actionable steps:
In a lot of cases, a 2nd phase isn't needed at all, because we just need to offer the users a good enough implementation so that they get the job done. A view I strongly hold and often sparks some criticism or at least some raised eyebrows, is that I often go for the "good enough" rather than the best and perfect solution. I am a huge adept of the 80/20 thinking (80% of the results are from 20% of the actions), so I usually try to identify and focus only on the most important aspects of an implementation. I don't really care about providing 100% coverage of all the edge cases that have a very low chance of ever happening. The most important aspect is to get to provide the right feedback when such case occurs (eg. a simple "Something went wrong" and a Sentry notification with the proper technical details and context are enough) and avoid data corruption, which can be done with transactions (eg. when we do 3 inserts in a single operation, and we detect an usual case after the 2nd insert but before the 3rd, it is important to roll back the first two because we don't want to end up with partial state persistance in our database: kind of hard to recover from there).
When deciding if a certain UI change is needed, it is crucial to have a conversation and understand the necesity of this change. In a lot of cases, you get pushed for small low impact changes that feel more like chores or busy-work rather than something that really advances the product. Having a conversation about the underlying "why"s of this change helps put some context around it (what problems are we facing? what problems are the cusomers facing? how did we obtain this information?) and plan from the solution for that problem (how do we fix it? how would the perfect solution look like?). Then we figure out the details to get the needle moving in the right direction (is this solution achievable in a reasonable timeframe? if yes, we do it now or in 6 months? if no, can we reduce its scope so that the end result is still good enough and fix our initial problem, at least partially? if yes, how do we iterate on it so we can break it down in multiple deliverables, if no, how do we manage our resources to also be able to advance on other areas in the same time?