Good User Experience 101

This week I will give some basic practical tips and information when trying to create a good User Experience for your application. You can elevate this to the level required for the project, but on this post I want to keep it basic. If you remember the following guidelines, you will create a better user experience.

  1. Pretend to be the application user

    Maybe you could come up with this yourself, but if you want to make sure your users will fully benefit of your work, you must sometimes step aside, and start thinking as the actually user. Whether you’re a project manager, developer, designer or fulfill any other role, it is very important to start “using” your application as the user. Just walk trough every basic scenario in their position.

    • Are they behind a desk, or on the road.
    • How long are they able to stay focused on the application, or are they frequently disturbed.
    • How many steps do they have to take, and aren’t these too complex to comprehend. Maybe more steps, but with less fields, or visa versa.
    • Do they think it’s logical that you first have to resolve one “order” before they can open the next. Or do they work on multiple items simultaneously.
    • What does the “an error has occurred, please contact the administrator!” message mean to my work. Is it saved, or is it lost. What is the problem, and how can I work my way around it.
    • Whow, that’s a lot of fields. I’m not feeling like doing all that now, maybe later…
    • Where in the application am I, and where do I go from here.
    • Why can’t you accept it, what is wrong with it, where is it wrong, and why…
    • Oh no, now i can start all over again just because i forgot to fill in the entry date. Forget it, I’m not going to do it again.
    • I can’t remember how to get to that screen where i could find all the items currently available.
    • Does this button mean saving this, or everything. Does it close it. Is it ready now, or do i still have to do something with it.
    • Why do i have to do all this over again, all these questions are already known.
    • Can is safely close the application now?
    • etc…

    In their point-of-view sometimes things doesn’t seem to be that logical as what you thought when you first designed it. They are not in service of your app, the app must help them do their work better. It must take your user by the hand, and lead them trough all the actions needed for doing their job. Try to pretend you’re that user, and forget everything you’ve learned while on the project, and see if the application does help your users, or only makes their work more difficult.

    Sometimes you can’t escape complex situations. Your users may then not fully understand the application. But they do understand their work. So if they match closely, complex situations will be able to explain themselves through the way your users do their work.

    A thing to remember is that you always have to provide feedback. In one way or another, let the user know that his action did something. If it is busy or ready or completed. Show what elements are updated. Did something fail, and why. etc…
    Make sure that this feedback is understandable. The user must know what it means and how it is connected to the actions he/she just did. This way the user gets the feeling it is in “control” of the application.

    You may want to take this “pretending” to the next level, where you’ll test the scenario’s with prototyping and user-tests. Because this post is a “101” I will skip this subject for now.

  2. What is the application trying to achieve

    In addition to think as the actually user, it is also a good thing to remember why you are actually building the application. One of the statements I use for implementing UX in a project is:

    User Experience Design is necessary in every project because it is the only way to achieve the purpose – working quicker, more efficient and cheaper – of the application.

    If you are working on a non-commercial application, you can let the “cheaper” part out, but nonetheless, quick and efficient still applies. The application must be used to support the user doing a certain task. And you want him to do this as quick and efficient as possible.

    To reach this goal, you have to think if the way you had in mind for a certain functionality is the quickest and most efficient way of doing that. When these two collide, I personally prefer efficient before quickest, because indirect that will speed up the use of the entire application. And with quick and efficient reached, cheaper often comes automatically.

    When you keep this in mind every time you describe, design, develop or implement a functionality, you are really working towards a good user experience for your application.

  3. Rules of engagement

    Maybe this step is a little too much for a “101” post, but I think it doesn’t hurt to mention it. This is actually something that can be used for larger projects (multiple designers/developers without a short line of communication). In these situations you can use certain “rules” for user experience design. Everybody who works in the project have to obey these rules. Making decisions about functionality and presenting them will become less difficult. A good example of this, is the project team which developed Office 2007. There they called these rules Design Tenets. And the rules they made where these:

    • A person’s focus should be on their content, not on the UI. Help people work without interference.
    • Reduce the number of choices presented at any given time.
    • Increase efficiency.
    • Embrace consistency, but not homogeneity.
    • Give features a permanent home. Prefer consistent-location UI over “smart” UI.
    • Straightforward is better than clever.

    Jensen Harris of Microsoft actually gave a pretty good presentation about using these tenets in a MIX08 presentation which can be viewed here (he starts on this subject at 00:33:00).

    I will lift out the example he gave about using tenets. It’s about the paperclip assistant “Clippy” which occurred in previous versions of the office-suite. Because of the tenet “Straightforward is better than clever” it was impossible to re-implement such a solution in Office 2007.

    You can actually re-use the tenets used by the office team in your own project. They pretty much can be applied to every application that must be build. And when you do and they are followed, i think your application will have a great user experience. Although I do understand that this may be a little too much for the smaller projects.

So briefly, it shouldn’t take a specialist to improve the user experience of your application. Just try to think how your users will work with it, and why you are making it in the first place. If this will be the base of your work, I am sure that you will create something beautiful that your users will love to use.

p.s. In a little addition of user-friendliness, let the system do the talking when it comes to a 404.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *