| I try to think UI-first. When I start a project it's not "How do I implement this functionality" it's "How do I make this UI". UX is a lot deeper than where the buttons go, it's about workflow, and architectural decisions can constrain UI. Using a UNIXy suite type model? You might have trouble editing an earlier decision without undoing all work after that, unless you are very careful. Some architectures might make auto discovery and drop boxes hard and users will need to type IP addresses themselves. I'm convinced a top notch UI has to be a goal from the start, or it will take twice the work. Good UX means the actual functionality is designed based on the psychology of the users, not the logic of the task. An undo button is worth more than beautiful code. 2 redundant buttons that do almost the same thing, that could just as well be done by manually entering parameters, is fine if that's what users want and it will save time and stop mistakes. You're not modeling a task, you're modeling how a user does a task. Next up, white space. It really is important. Packing 200k things on screen will annoy everyone. Modern UI design might disappoint some in terms of aesthetics, many people hate the ultraminimal look, but the layout is pretty good and paying attention to how everyone else does it makes sense. When was the last time you needed a manual or google to use an Android app? Almost never for me, because they are self documenting and things just work. |
If you're building a specialist, usually business, application then often all the users will be power users fairly quickly, because they will spend all day every day in your application. In this case their priority will be doing things quickly and accurately, and having all the information they need available when they need it. My priority as a UX designer in this instance (or my priority as a designer herder these days) should be enabling them to do this, and not making stuff look pretty and well spaced in the first instance. This will often involve cramming lots of information and icons into a small space and minimising white space, and will sometimes involve making an application hard to use for newcomers. And that's fine! If it is a bit of software that someone is going to be using 40 hours a week for the next 10 years then the priority is the user who already knows the system, and not the user who is learning the system. Although you need to ensure that the system is actually learnable, which is largely about consistency, documentation (gasp!) and tutorials, and surfacing the most frequently performed actions.
I just went through a battle with a UI designer who wanted to break up an existing interface used in a marking tool into several screens because the current UI was hugely cluttered (which it is) and intimidating (yep, looks scary) and hard to learn (actually not, onboarding of a new user takes about 30 minutes. 25 of which is them following a long to a video). The design they came up with would have looked much nicer, but would have resulted in a much poorer UX, as it would have involved the assessor switching between multiple tabs, scrolling up and down and dragging and dropping items across the screen. And doing this literally thousands of times over the course of a couple of weeks. I'd already been through a similar battle with a previous UI designer to eliminate drag and drop in the same interface a couple of years ago because I had a user develop RSI using it. In doing so I made the I terrace uglier and more cluttered but eliminated many hundreds of drag and drop actions a day for each user.
Anyway, moral of the story, sometimes a good UX is only possible if you have a "bad" or at least ugly and cluttered UI. This doesn't mean that you should ignore aesthetics, or go out of your way to make things ugly, but that sometimes cluttered, information dense and unintuitive to new users is the way to go.