The first part of this article was about the treacherous intuitiveness of establishing an HMI styleguide based on a Corporate Design (CD) styleguide, and why this decision is risky: unlike a CD styleguide an HMI styleguide has to work for software engineers as well as visual designers. Also, this form of documentation is too rigid for a dynamic modern HMI. The most important insight: an HMI styleguide cannot be the sole basis for developing a consistent, aesthetic and intuitive HMI. Looking back on many years of big HMI design projects and speaking as a UX consultant I can say: only a combination of tools and processes will lead to success.
Thinking Out of the Box
Posts Tagged ‘Documentation’
Intuition seems to be one of those things we all profit from a lot. But at times it will deceive us. Designing an intuitive HMI seems to be one of the highest priorities of modern software development, minimizing both the need for training and the risk of operational errors. Still, a lot of software engineers and even HMI designers stumble into one trap when aiming for intuitive software design: listening to their own intuition. They will tell themselves, and quite rightly so, “A good HMI design has to be aesthetic and consistent, so that operators will be able to profit from already learnt patterns in a new context of use – if they can use one machine, they can use all machines.” So far, so good. But now comes the misconception: “If you want your HMI design to be consistent in every way, why not adapt the already established corporate design? It has been there for ages, guiding along the way to consistency and brand experience: the corporate design (CD) styleguide”.
Alas, this is the wrong analogy – but not the first time it has been used: the early years of television had the same problem, reading the daily news to their audience the same way radio did, or the early years of the internet, displaying long columns of information in serif fonts, just like contemporary newspapers did. This might have felt intuitive because it was well-known and long-established – but it was still wrong.
The philosophy of a CD styleguide cannot be transferred to a modern HMI and its development.
Communication is essential to UX design. As with other contexts, communication can be impaired by – sometimes very subtle – influencing factors, some of which were described in part 1 of this article. This second part of the article deals with additional aspects that can be detrimental to communication, such as (unconscious) language barriers and the “human factor” in UX design.
There is a multitude of roles and job titles in the field of UX design. But regardless of what the involvement of someone in a UX design project is – communication is a key activity when it comes to successfully accomplishing many of the tasks in the collaborative domain of UX design.
Whether with users, project stakeholders or within a UX design team, “communication” entails much more than simply talking to respective receivers and making sure that the words come out right. There are certain pitfalls to avoid. This two-part article examines the role of communication in UX design in order to provide information that helps in communicating efficiently. In the article, the term “UX practitioner” is used to refer to the diverse roles in a generic fashion. The ideas described can be applied to in-house as well as external (consulting) UX practitioners.
Wireframes are an essential tool in the usability engineer’s toolbox. They can be created easily and support communication regarding fundamental layout and interaction design. Usually, little to no resources are spent on visually “styling” the wireframe in order to efficiently focus on the fundamentals without investing too much effort in visual details that are likely to undergo significant visual changes later.
If members of the design team / stakeholders lack experience with using wireframes, certain problems can occur that may impair a user interface design project, two of which shall briefly be described.
“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.
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. read more…