In my experience, having even a little bit of exposure/internalization of UX and UI design principles makes a huge improvement in what I create. Without considering design, you can do everything technically right, but users might still hate the result. And even subtle changes can drastically improve things. For example, we devs might label something in the UI for its technical attributes: like "public notes" -- a notes field which is public. But the technical attribute means nothing to the user, so their System 1 thinking will automatically classify the information as irrelevant. And they will never even notice it. Instead, they will contact support to ask a question which is already answered by those public notes. But if it were named something relevant to its purpose in their workflow like "Account Problems", they have an increased chance to notice it. So a simple relabeling of the field could prevent a number of support incidents. But as a dev it is all too easy to think only of the technical. And technical excellence alone is not enough for success. Practical design exposure helps to expand the perspective.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@picocreator is spot on.
In my experience, having even a little bit of exposure/internalization of UX and UI design principles makes a huge improvement in what I create. Without considering design, you can do everything technically right, but users might still hate the result. And even subtle changes can drastically improve things. For example, we devs might label something in the UI for its technical attributes: like "public notes" -- a notes field which is public. But the technical attribute means nothing to the user, so their System 1 thinking will automatically classify the information as irrelevant. And they will never even notice it. Instead, they will contact support to ask a question which is already answered by those public notes. But if it were named something relevant to its purpose in their workflow like "Account Problems", they have an increased chance to notice it. So a simple relabeling of the field could prevent a number of support incidents. But as a dev it is all too easy to think only of the technical. And technical excellence alone is not enough for success. Practical design exposure helps to expand the perspective.