Monday, September 2, 2013

the core principal of good interface

I think about shit in my free time. I think about things that I interact with, that I use. And I've decided that there is one core principal that should govern UI design (or interactive design in general). Here it is:
Success in design is measured by how easily a user is able to articulate his will to the application
I think it's kind of simple, but there are nuances. For instance, sometimes the user needs to learn how to actualise his will to the machine. Just as you cannot communicate before you know how to speak, sometimes you must learn the machines language before being able to speak to it.

For example, I used to play a lot of Halo. I played so much Halo that I was able to move my avatar in the game as easily as I can move in real life. It became instinct and muscle memory; initially I had to think about pushing the sticks in the right direction to get my guy to move over to where I needed him to be, but now it's as simple as me just moving over to another chair in a room. This is success in physical design (the controller and the inputs), software design (esp. for aiming in Halo; controller auto-aim is absolutely necessary for users to hit what they're shooting at without feeling like it's unwieldy), and I also practiced a lot.

Let's take another application. Why not blogger? It's what I'm using right now and it's easy enough to repro.

First, the good: Blogger caters to people making and posting on blogs. Creation of the blog is stupid easy; from blogger.com when I'm logged in I can easily see the new blog button on the left side of the page. It's separate, I don't have to look hard to find it, and i can just click, pick a name, url, and template and i'm good to go. That's awesome for the average use case, and executing my will of creating this blog was trivial.

Design of the blog was a bit more tough, but it's a more complicated operation. I'm not writing the js and html myself, so I'm dealing with the UI of blogger for design. From the url of the blog, I'm able to click on "Design" in the admin bar. From there, I click "Customise" and I'm golden. I got rid of the background, changed some fonts, changed a few back, then started fucking with the layout.

I didn't really know what I wanted here, so I got rid of the sidebar. I didn't like where it put the About Me widget, so I deleted it. Then I couldn't figure out how to add it back in. It told me to go to "Design > Page Elements" to add widgets, which helps none at all when I don't know where that is. A protip: Just add a link if you're directing a user elsewhere. Directing a user to go elsewhere is fine if they know where you're directing them, but I have no idea where "Design > Page Elements" is. Well shit.

I went back to the main page because I know that there was a link that said "Design." That gets me back to where I was, with no "Page Elements" in sight. Turns out the way to change it is to access the blog from the Blogger dashboard, go down to "Template" and click the orange "Customise" button under the rendering of the blog. Not only were the instructions given not helpful, they were incorrect. Which is gross. But I found it and the UI for adding the widget back was p nice, so I can't complain too much.
The hardest products to design for have the most features. I'm going to call out Photoshop here because that shit is magic to me. I don't know where all of the tools are, I don't know what many of them do, so I always have a lot of trouble forcing my will onto images. But there's only so much you can do in that situation; when you open up an image, Photoshop doesn't know what you want to do with it. So you have access to everything, and it's on you to pick the right tool for your job.

That's not to say that you can't optimise; the easiest optimisation is consistency. If tools have attributes/values that you can modify, put them in the same place for every tool. Then when a user wants to change a setting, he'll know exactly where to look: where the settings "live." Change is good a lot of the time,  but in usability designing, it's better to be consistent than to be constantly innovative.

I guess the main takeaway from what I'm talking about is that on any given stage of an application, you should know the use cases. Ask yourself why the user is there, and what they're most likely to want to do from there, and make it obvious. How to make things obvious is an important topic covered at length by many others, so I'll not rehash. But I think that you need to make the right decisions on what actions to make easy (a single button, obvious and clearly labelled) and when to hide the plethora of options that are available (dropdowns, expansions, and menus).

No comments:

Post a Comment