There are several apparently axiomatic design principles that purport to be perfectly adjusted to the human cognitive system. Their prominent characteristics are that they are broadly applicable and easy to grasp for the psychological layperson. Unfortunately, however, they are usually false. One of these principles is the “magical number seven”. Very loosely based on an influential article by Miller (1956), this “magical” number provides designers with an easy guideline to estimate how many elements their products can maximally contain without overcharging the cognitive capabilities of their users. Generations of designers were forced to limit, for example, steps in a workflow, tabs, items in dropdown lists, links, choices, bulleted lists, radio buttons and checkboxes, to this apparently magical number (cf., e.g., Eisenberg, 2004). As every myth, there is also some truth to the “magical number seven”. I here give a brief overview of some aspects of research on cognitive capacity limitations from a basic experimental psychological perspective. Although the here discussed insights are not as magically applicable as some would like, the present overview might be of use for the interested UI designer.

This article was inspired by two interesting days at the GUI&Design conference that took place just recently on 8th and 9th December in Fürth, Germany. The conference audience consisted of professional user experience designers and developers and the talks and workshops focused on Microsoft user interface technologies such as WPF and Silverlight.

Not only this article is a spontaneous creation – one of the activities I participated in during the conference was, too: Clemens Lutsch, User Experience Evangelist at Microsoft, asked me to join a discussion panel in order to conclude the first conference day and discuss concepts and roles in the UX domain with regard to aspects that are challenges in our daily professional work.

For me this was an excellent opportunity to discuss a term that we have introduced at Centigrade a couple of months ago: “user interface design engineering” or a bit shorter “UI design engineering”. Having used the term just internally in the first place, we started to bring it up in conversations with our clients and partner companies more and more frequently – with great acceptance. When I brought up the term during the panel discussion, I observed similar acceptance from the audience and my co-speakers – almost as if the term closed a gap that many professionals felt has existed for quite some time. It was even picked up by other conference speakers, right the next day, which motivated me to shed some more light on the term and its meaning. So, what is UI design engineering, anyway?

Three years ago, we published a blog article that shed some light on the development of the iPhone. The motivation for writing the article was the fact that the iPhone was often used as reference when talking about usability goals and user interface design ideals and that design requests often could be roughly summed up as “Make it like the iPhone”. The blog article described of aspects of iPhone development that did not get the same publicity as the product and its user interface themselves. Those aspects were

• Apple’s complete control over design, manufacturing and marketing,
• a completely new operating system that had been created and
• the considerable effort in terms of time and money that had been invested in the project.

In the meantime, Apple has created several new versions of the iPhone and even included a completely new product in its portfolio: the iPad. After those success stories, it is no surprise that reference to “user interfaces like Apple” is still made. It is therefore appropriate to revisit the topic and add some insights regarding the “Apple design process” in general that have become known to a larger public, not least through the Steve Jobs biography. Such insights can prevent misguided approaches in which Apple-like results shall be reached without implementing a corresponding process.

Texts are important parts of most user interfaces, be it, e.g., as form field labels or longer help texts. This article is aimed at providing a common introduction to the topic „choosing the right font”. It contains some hints an pointers that simplify the search for the right typeface.

The first part of this article provided an overview of the concepts of the currently implemented user interfaces for the Kinect™ sensor. It pointed out technical specifications and explained the human-machine interaction within Kinect games. This second part now scrutinizes this interaction and assesses its potential for industrial application.

In November 2010, Microsoft® introduced Kinect™. As an expansion of the Xbox 360™ gaming console, it brings controller-free gaming to the living room and even long before its actual release it was believed to revolutionize Human Computer Interaction. Therefore, expectations were rather high and one felt reminded of the Natural User Interface (NUI) featured in the movie Minority Report. Will this futuristic vision soon become reality?

To our great delight and surprise, our animated Facility Manager Prototype and respective Blog article was used as demonstration and reference material at UXCamp Europe 2011. In regard of the apparent interest in the topic this article picks up the issue yet again, focusing on scientific considerations of the past years.
Indeed, animations have become an integral part in today’s modern applications, especially the iPhone and Co. Having this said, it astonishes that scientific efforts are still in fledgling stages and that the few existing approaches vaguely draw upon techniques and rules used for cartoon movies. At the same time however, choosing the wrong animation will literally paralyze a User Interface.

The first part of the article dealt with potential causes for wrong expectations regarding usability, that lead to perceptions of “usability as a product” that can be acquired right off the shelf and then implemented into a user interface. This part describes how the UX designer can cope with these challenges in order to create realistic expectations and conduct a successful UX design project.

Sometimes, prospective clients request user experience designers to “bring along some ideas” for a first meeting. The thought behind such a request can, e.g., be the desire to get some inspiration regarding the look of user interfaces, which is legitimate.

The problems start when the request is made with the expectation for the user experience designer to bring along ready-made solutions that can more or less directly be used to optimize an existing user interface – a “usability catalog” from which the client can choose the right solution, which can then be provided without much delay.

This article deals with the question why this kind of “off the shelf usability” does not exist and which causes can potentially lead to these expectations.

Comparing computer games with “serious” software applications may seem like comparing apples and oranges if we think of serious software as tools that allow users to achieve mission-critical productivity goals in their working live. In this respect, the two industries couldn‘t be further apart regarding their target audience and the way they rank productivity vs. fun. For this reason, we are oftentimes asked why Centigrade as a “serious” user interface design company collaborates so closely with the game industry and even has a branch office located in a building that’s otherwise occupied solely by game development studios.

Yet, the link between computer games and industrial software is more obvious than one may think. To summarize why we believe computer games can have a positive impact on the user experience (UX) of industrial software applications, this three-part blog post provides a bulleted list of ten arguments we keep on stating in this regard. The first part gives a high-level and process-oriented perspective on the topic, the second part will shed more light on the transfer of aesthetic and interactive aspects found in games to serious software and the third part will have a look at the game industry as a technical driver for innovations that spill over to other software industries.

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.

Corporate design guidelines aim at ensuring a coherent and consistent corporate identity. User interface guidelines (or UI guidelines) work in a similar fashion. They provide a set of rules for designing a software’s user interface. This applies to visual design as well as to interaction design. Ideally, adhering to these rules guarantees a basic quality of applications that run on the same operating system and avoids an “application zoo”-scenario.

Interacting via touch is on everyone’s lips. Nevertheless, many companies shy away from reorganizing their applications respectively, because touch screen interactions require different concepts and can accompany huge restructuring efforts and high costs. Also, such restructuring is not riskless, since touch-interaction is not the most suitable paradigm for all application scenarios. The following article presents the combo box as an example to illustrate how mouse- and touch-interaction concepts can be integrated to get the best of both worlds. The article aims at inspiring especially those of you, who appreciate mouse- and touch-operation alike.

In one of our previous blog articles we talked about the use of pie menus in touch screen interfaces and discussed pros and cons of this kind of interaction. In this article, we are going to show a concrete example of how a pie menu can be used.

In order to successfully conduct user-centered-design projects, it is important for the team to have a shared vocabulary and understanding of key concepts. Grave misunderstandings can occur, when the parties involved use identical terminology, but the concepts that they refer to diverge. This starts with terms like “usability” or “user experience”, for which – in the worst case – you can find as many different explanations as there are members on the project team. Confusion can also arise regarding the concept of “interaction design”.

In recent years, so called “natural user interfaces” (NUI) have grown in popularity. More and more often, interaction via touch and gestures is employed instead of using mouse and keyboard. The iPhone was greeted with great enthusiasm and played a major part in spreading touch screen system in the consumer market while also introduced gesture-based interaction in a playful way. There should be hardly any touch screen user who is not familiar with the pinch gesture that is used to resize or zoom images on the iPhone.

Keeping the background information of the previous article in mind, assume you want to make use of Blend to design a NUI based on Silverlight or WPF that lets you easily manipulate items on the screen. In the beginning, you won’t even touch the tool at all – you “invent” whatever gesture you think is intuitive to perform this operation. Most likely you do this in your head or on the whiteboard. You discuss and refine the design with your team mates or with potential users. At this stage everything is still low-fidelity and throwing away things isn’t costly yet. As soon as you have a good-enough feeling about the rough design, you start prototyping with higher fidelity. This is to be really sure your idea works. To provoke the intended interaction experience, caring about every single detail is exceptionally important in later prototyping stages.

Every user interface designer is familiar with the procedure to some extent: To find out what a user interface needs to look and behave like it’s certainly a good idea to create a prototype and evaluate it with potential users. Users will tell you what’s still nagging them and therefore should be improved before coding starts. So, in the beginning of any UI design process everything is about change – you create a prototype and already expect it to require modifications in order to work alright. As you – and most likely your client, too – want changes to be as cost-efficient as possible, you are better off taking a change-friendly prototyping method or tool. This is especially true in early stages of the project your ideas of potential solutions are rather vague. In this early phase, most often you don’t even know the exact problem for which you are in hunt of a solution. You are still analyzing more than you are designing.