Who Needs Usability Engineering, Anyway?
“Who needs usability engineering, anyway?” – This is a question that one might hear from people whose experiences with usability engineering services have not been too good.
“Who needs usability engineering, anyway?” – This is a question that one might hear from people whose experiences with usability engineering services have not been too good.
In the previous part I gave a quick introduction to resolution independence. This part explains what technical limitations exist that complicate the job of creating high quality resolution independent icons.
About two years ago there have been some lively discussions on resolution independent user interfaces in the context of icon design. An interesting start page for past discussions is Sven Porst’s blog article. At that time, resolution-independent UI-related products such as Mac OS X Leopard, Windows Vista or Silverlight were either yet to come or have been used solely by a small bunch of insiders. Now, almost two years later, these are established brands – reason enough to shed some light on this topic again and to see if something has changed during this time, and if so what.
With all the “advanced topics” on usability engineering floating around in the blogosphere it may sometimes be hard to find information on the fundamentals, so we are providing this primer on the involvement of end users in the development process. This is basic information, but for some readers it may also be information they always wanted to know but were afraid to ask for. After all, you have to start somewhere.
An essential part of designing user interfaces consists of communicating about system behavior and functionality that has ultimately to be provided in the user interface in a user-friendly manner.
To transfer knowledge regarding system behavior / system functionality, a variety of methods can be used. Often, use case descriptions and screen scribbles are employed to provide the required information. When a user interface designer has a kickoff meeting for a project, for example, a stakeholder can scribble a screen that would provide essential system functionality so that the user interface designer gets a quick impression of certain system aspects. During requirements engineering, use case descriptions might have been created that are handed to the user interface designer to get a feeling for workflows that are carried out and the desired user-system interaction.
Both ways of documentation have their advantages and drawbacks.