5 ms·

Tweaking that stuff early on is so effective that it could almost be thought of as a "cheat code" for development. User perception is greatly enhanced by a few

Tweaking that stuff early on is so effective that it could almost be thought of as a "cheat code" for development. User perception is greatly enhanced by a few hours of tweaking padding spacing etc., rather than a few months or years of deferring that tweaking.

codetrotter 9y ago
> User perception is greatly enhanced by a few hours of tweaking padding spacing etc., rather than a few months or years of deferring that tweaking. Some of us explicitly don't want the UI to give off the impression that the software is more finished than what it really is, so we sometimes intentionally keep the UI unpolished while we know that we have important things not yet implemented. However I have come to realize that there are several downsides to this line of thinking; 1. If the app looks bad then it might permanently put off would-be users. 2. By not giving the UI enough attention early on, discoveries of UX problems that could have been caught early are not made until much later, delaying the project and potentially leading to more work as well because there will be more things that need to be rewritten or remade in order to fix the UX problems. 3. If you think feature X needs to be completed before you do the UI, then what is going to keep features Y and Z and so on to make you think the same way when you get there? Software is often never "complete". If you think it needs to be "complete enough" before you can give it the UI it deserves, how will you know that you've reached the stage of complete enough? Furthermore, I have come to realize that often we don't know what we want exactly. We might think we know, but as we work on implementing our ideas things turn out to not be quite as we'd imagined them to. But I also think that grand parent was on to something. When we build software, we should strive to implement features that are useful but not only that, the software needs to make the most common tasks as efficient for the user to perform as possible. And in order to find out what that means, we need to consider the UI from the very beginning.

codetrotter 9y ago

> User perception is greatly enhanced by a few hours of tweaking padding spacing etc., rather than a few months or years of deferring that tweaking. Some of us explicitly don't want the UI to give off the impression that the software is more finished than what it really is, so we sometimes intentionally keep the UI unpolished while we know that we have important things not yet implemented. However I have come to realize that there are several downsides to this line of thinking; 1. If the app looks bad then it might permanently put off would-be users. 2. By not giving the UI enough attention early on, discoveries of UX problems that could have been caught early are not made until much later, delaying the project and potentially leading to more work as well because there will be more things that need to be rewritten or remade in order to fix the UX problems. 3. If you think feature X needs to be completed before you do the UI, then what is going to keep features Y and Z and so on to make you think the same way when you get there? Software is often never "complete". If you think it needs to be "complete enough" before you can give it the UI it deserves, how will you know that you've reached the stage of complete enough? Furthermore, I have come to realize that often we don't know what we want exactly. We might think we know, but as we work on implementing our ideas things turn out to not be quite as we'd imagined them to. But I also think that grand parent was on to something. When we build software, we should strive to implement features that are useful but not only that, the software needs to make the most common tasks as efficient for the user to perform as possible. And in order to find out what that means, we need to consider the UI from the very beginning.