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 ‘Communication’
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.
I can still remember the moment when I was up in the sky looking down on Frankfurt, anxious yet excited. In June 2015, I moved from my hometown Hong Kong to a country known for its beer, sausages and miserably cold winter – Germany. It was indeed pretty intense for me as I had never travelled to Europe before. And when I did, I started living and working as a UX designer there.
Being International: More Than a Matter of Geography
After going through the culture shock, I realized that being a truly international designer is more than just a matter of geography. Travelling and living in another country won’t make you international if you are narrow-minded, reluctant to look further at the cultural influences behind those behavior and thoughts that you find it hard to identify with. read more…
Please take the following with a grain of salt, a slice of lime and a big portion of good-natured humor: Below we dive into the fictional world of a very naïve designer. The situations are exaggerated on purpose to illustrate some of the difficulties designers can fall prey to when they do not have an overall understanding of the design process with its stakeholders on client- as well as on user-side. Each issue of the fictional designer is contrasted with that broadened perspective.
The first Feedback
Monday morning. I am launching Outlook and, behold: The e-mail I sent on Friday has just been answered. There is feedback on my newest design – yay! With a humming growing louder and louder in my ears I read that almost everything looks ok – which, of course, to my artistic soul feels like a slap in the face! Because “…almost everything…” and “…looks ok…” basically means that my, oh so perfect visual concept will be taken apart.
All my work for nothing! Researching for hours to find the perfect font. Putting so much thought into every margin. Wisely selecting colors with the pantone catalog I stole from the hardware store specifically for that purpose. And now someone dares to demand changes to my creation? Did da Vinci have to make changes to the Mona Lisa? Did Picasso do usability tests? Did Van Gogh ever read his e-mail? Who knows… I, for one, know immediately and with certainty: After all the changes that are being demanded the design will be ruined and, adding insult to injury, I will have to be the one to destroy that work of art.
The term UX design is used very often nowadays. In most cases it’s either used as synonym for interaction design, usability professional or a similar denotation or as conglomerate of all of these disciplines. It is recalled that UX design is not only a phase, but that it should be applied throughout all phases of a project. For me, the boundaries of the term are still set too narrowly. Everybody involved in the development of a product has significant impact on the resulting UX. Usability engineers, interaction designers, visual designers, design engineers, project owners and developers.
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.
User interfaces should provide great user experiences in order to be successful. Organizations often make use of the services of external agencies, such as Centigrade, to support them with the creation of outstanding user experiences. In the long run, however, it should be the goal to create the soil, on which successful UX design projects can thrive, within an organization. This does not necessarily mean that an organization must do all UX related activities on its own without relying on outside help – there should, however, be an organization-wide awareness and appreciation of UX and basic knowledge and capabilities should exist in-house. The following article describes some aspects that should be taken into account when trying to create such a “UX culture” within an organization.
User interface prototyping is an essential activity in the field of user interface design that provides a basis for continuous evaluation and improvement of a to-be-designed user interface. In usability engineering, the focus of using prototypes lies on evaluating the usability of intended approaches and on generating concrete recommendations for advancing an interface design. While doing so, there are several aspects to keep in mind in order to maximize the efficiency of prototype use for usability engineering. Three issues are described in this post.
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.
“Can’t we all just get along?” – On the Cooperation Between Usability Engineers and Software Developers
It is still a common complaint uttered by usability professionals that organizations in general and software developers in particular “just don’t get” usability engineering. They are frustrated because they have all good intentions to provide support for creating user-friendly systems but the reactions they get are reserved at best and developers simply don’t buy into the whole usability engineering process.
So, whose fault is it? Who is it that is just not getting it?
As often in life, it takes two and an occasion to create a problem. Let’s have a closer look.
“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.