If you are an engineer or developer consider this; It's always interesting when the battle between function and UI/UX as a priority takes place. On the one hand you have the point of view that "if nothing functions, who cares how good it looks" and on the other you have "sure it functions, but who cares if you can't use the thing and it looks bad".
So how do you choose what is the priority?
BTW if you prefer to listen I go into greater depth on UX in episode 13 of the engineering podcast.
Let's consider 10Up
10Up is one of those games where an individual puzzle itself can be entertaining. Depending on its difficulty determines how much mild entertainment one would have in the exercise. So the real game is built upon repetition and solving as many as you can against the clock. So this has always had several design challenges especially considering both UI and UX. In 10Up 1.0 it was imperative that I had function down and whilst considering some UI, no care was taken into UX. I thought I had this middle ground between getting function and some form of UI/UX.
Engineers typically prioritize function
Here's where it is a problem for most engineers: It was a math problem, and you have the tools to solve it. This is where functions matters above all because without function who cares what it looks like. The software is a tool, similarly like a hammer as a tool, you wouldn't care if a hammer looks good or ugly, can it pound these nails? - No one wants an expensive pretty hammer that can't even destroy a paper cup.
Well, here's the thing, this comparison is actually not complete enough to be comparable. The equivalent of having poor UX on a hammer (although not entirely feasible) is knowing you have a hammer but not knowing where the handle is. Or when you grabbed the handle, the head would shrink for some reason and you had to press a secret "smash things" button to make the head expand to the functional mallet you were asking for. So the current issue with 10Up is the user flow for a human to solve a puzzle was not intuitive. It was hard for me to understand this as I could work it out, all the tools were there AND I added some colours to indicate where to be looking. I just needed to explain it once and the person could play easiliy. So I focused alot of the advertising and marketing on including some game play working through the puzzles to educate.
But here's the punchline:
A User Interface is like a bad joke. If you have to explain it, it's not very good.
So now we know that User Interface, similar to User Experience is important because people can't use the tool. We understand that the purpose of a tool, aside from is function, IS to be used. But here's where we say, "but, I have a deadline of yesterday and I don't even know if the thing works or not! I can't be wasting time on user interfaces!"
How do I get more time to focus on UI?
Well thankfully you read this article. Here's how you "make time" for considering your User Interface. The more you practice it, the better you get. It takes just as much time to make a poor user interface as a good one. Remember -it doesn't have to be amazing and completely polished (much like the functions) but if you consistently consider UI even when building new functions, it becomes second nature, like driving a manual and you won't be discussing this again.
UI is different to UX but the mindset about them does go hand in hand. In episode 12 of the engineering podcast I go in depth about UI if you prefer to listen.
It's about balance.
I am not suggesting you spend 20 hours on UI/UX and 5 hours on function and after one full day you have something that doesn't function. I'm saying as you build your functions instead of creating that default object, you set a few variables and place some frames around it. You include what you need to and you are fast enough that there is no detriment. Now if I'm not done convincing you, here's the final kicker. At the end of the day the tool you are building should be designed in a way that it could scale if necessary, or bug fixes can be resolved. Half the problems from the client will be caused by UI/UX problems.
By contract a customer or client may say "Function A is a necessary requirement" and you can focus on it being perfect. But at the end of the day the first thing the client wants to see is the interface. And when you've got this scrounged up last minute interface, the work behind already seems like it is rushed as well. For future you - you will be building functions and bandaid fixes purely because of your poor UI!
So work on your UI/UX skills from the beginning!! Now for some bonus content have a look below for some exploration of 10Up user interface within the game. A point and drag system to a central point as this will push users to understand that they are combining items one by one.
Now, if you are still having troubles on this topic, here's a technique I use to get my subconscious to solve problems for me. Perhaps you can use this technique to figure out how to solve your lack of UI/UX mindset being applied to your current solutions.