It turns out that I finally get to understand what I would like to specialize in, a designer of user experiences in the field of I(C)T. But what should that entail? What is it that a User Experience designer can add to the value of a project?
A project starts with a goal, or maybe more like a question, e.g. 'I would like to have something that helps you in getting X done'. If you think about it, solving X may be simple. You gather a set of requirements, translate these requirements in a nice graphical user interface, which may even correspond to all accessibility guidelines available at that time and would work of course flawlessly from a technical perspective, and get it implemented. If done correctly, the client will initially be happy (because it does exactly what it was supposed to do, and you may have gotten him or her to agree on a few sketches and flowcharts you drew in the meantime). Such a process, however, is not considering the needs of the actual users. It is hard to get the right answer on the question 'what do you need?' (and also, 'what is it that you do not need?') before a product has been developed. It is even harder to answer 'What do you think your users need?' If one gets the chance to talk to users, they might be able to make some kinds of wishlists, or even drawings explaining wished for behaviour, but simply adding such suggestions as features is not a right way of designing. It is a flawed process because the construction of the feature list was already flawed. It is important to know which features are needed to accomplish the task appropriately. It should not be about whether the features are implemented, but whether the processes are improved.
Products are supposed to be used. Clients are ought to know what users want, and there are companies are able to translate requirements into something functional. But if you take a step back, it is not only a question about what a user wants, but also how an application can become actually useful. To create a successful product, one also has to think about how it should fit in the life of a potential user. A product may do whatever one wants to do (e.g. enable one to maintain contacts), it may even integrate with the PDA a person has (or not), but soon this person turns out to be really interested in yet another feature that would in his or her opinion really make the product better than what he or she had (e.g. some view that allows for a quick overview of everyone living at the same address or an easy way to connect to a program that prints personalized letterheads which is required on a daily basis). Many wishes are not revealed with simply asking the user what he or she wants, the user may not even know what they want. To really get an idea of what a user really needs is to interact with him or her. It is a shame that things like this get discovered when the development team has already left, or the it-department ran out of funds for further development in that year. Using simple techniques, such issues could have been discovered early in the process. It is about finding out the true needs of a user, not the hypothesized needs that are based on questionnaire like methods only. Don't only design usable tools, but useful tools.
To a user, a product is a tool, that should be helpful in getting things done. Nothing more. Of course it should be useable, but also keep usefulnes in mind. If you don't think about why some, in your view killer, feature is expected to be useful, you may end up quite disappointed with nobody embracing it as the distinctive feature you would like it to be. What is the use of such feature? Assuming that the products that you want to create are products that result in satisfied users it may help a lot when potential users are actively involved throughout the process. Through iterative design, with only a few users, using simple techniques, even as simple as sketches of interfaces, one may get a product that is not only conform all usability standards, but may also become a product that really fits the needs of its users and enhances their flow of work, not simply adds to their daily routine. Not just a usable tool, but also one that is useful.
Enjoyed this? Follow me on Mastodon or add the RSS, euh ATOM feed to your feed reader.
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .