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.

My mental framework related to UI decisions

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):

1. Who does it impact? Possible answers include: "a user who is trying to change their profile picture" or "a user who forgot their password".
2. What is the problem they are trying to solve?
3. What would the ideal flow look like? This is an important answer to get, because starting from this, we can actually start planning the adjustments. In most cases it won't be possible to create the exact perfect flow, but we can steer towards it. More than often, the perfect flow is based on the familiarity of the user with the task or the business domain they are active in, so it is important to design arount that. For example, in the e-commerce industry, you have to use the vocabulary that is often used in that domain, using things like products, variants, prices, shipping, orders, fulfillment, etc. You can't invent new things or bring up terms that are outside the user's familar vocabulary. It will create confusion.
4. How critical is it that we build it now vs in 6 months? Do we currently have users complaining about this area or feature being too obscure? Do we have to often instruct users to that area because they can't find it themselves? There is a trick question we ask ourselves very often, that might surprise you: do we even want users to get here easy? Some features are so advanced and targeted for certain users, that we don't really need to try to bring all customers there. Only the ones that showed interest in doing so will be able to use it, or for the features that were implemented to cater to certain clients, they will be able to get the most value out of it anyway.

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:

1. How complex it is from a technical point of view? Here, I try to estimate very roughly how complex it will be to build. Depending on how complex, how many team members need to be fully dedicated to it and what other ongoing work we have, we decide to either push the new thing further down the road, reduce its scope (by compromising some elements from the prefect flow, and going for a quicker "good enough" variant) or agree to go with it as it is in the current format.
2. Decide on the iterations needed to get it done. More than often, a new feature needs multiple iterations to get right. You push an initial version, gather feedback from users, make some adjustments (maybe some initial assumptions were wrong: for ex. we assumed they will understand what the "start import" button does, but in reality, they don't really grasp the concept of "import" that well, so we need to change it to "start uploading the products" instead).
3. Start making an implementation plan to get started. Usually here, together with the team, we come up with the actual implementation tasks needed to bring this new thing to life: do this in this frontend project, do that in the backend API, do this in some background task, etc.

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).

Conclusion

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?