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.
Figure 1: Centigrade is supporting TRUMPF to establish a company-wide HMI styleguide.
If you are going to be formal, be formal in the Code as well
The more formal your HMI design guidelines can be articulated, the less they should be confined to an inanimate document or half dead wiki. Generally speaking, any medium inviting lengthy prose or existing in a separate evolutionary lineage is unsuitable.
Modern markup languages let you convey design guidelines for the correct use of colors, icons, size and dynamic layout directly in the source code. Using HTML, CSS, XAML, QML or similar markup languages, effective templates for reoccurring design/development problems can be created. The HMI styleguide becomes a living specification.
Coded by specialized “design engineers”, these design templates meet both designers (and users) high standards for aesthetics and interactivity and engineers high standards for software development and coding. We therefore highly recommend markup language for HMI design.
Figure 2: XAML or HTML/CSS allow you to mold design guidelines for the HMI directly in the code.
The HMI Kit: a good idea when used with consideration
In the next step, HMI components that contain their own input behavior, navigation behavior, animation and visualization can be developed and supplied in the form of a central library – a company-wide building set which could be called an HMI kit. A very sensible investment, but also one to be well considered.
Doing things in the right order
Since those easily formalized rules are the most consumable and understandable to engineers they want to define them early in the project. To those who have learned and mastered the art of problem solving this feels right but is, again, a momentous mistake. Just like you should not build a sustainable software architecture from the view layer down, but from the service layer up, you should not develop an HMI framework starting with the obvious – instead, start with user requirements.
First, chart scenarios in as much detail as possible. All project results can continuously be mapped to those scenarios, usability and integration tested – rather than starting with logical units like colors, layout and controls.
Figure 3: Charting and prioritizing scenarios is one of the first steps to a successful HMI styleguide.
First the Frame, then the Walls
Ironically enough it is advisable to stay away from using the term “HMI styleguide” as long as possible if you are looking for a risk-free way to develop one. There are much more basic foundations that have to be laid down beforehand, foundations that in sum could be called a “Corporate UX Framework”. This is what you should aim for to establish and integrate UX as a business goal.
Similar to SCRUM a corporate UX framework defines an ecosystem of processes, methods, philosophies and roles that enable technical and creative artefacts to come to life and prosper. Describing all the steps for establishing a corporate UX framework would go beyond the scope of this article. It is advisable to consult with an experienced UX professional for this. But one fundamental point should not go without saying, because once gone wrong, it cannot be undone:
No more naivety: UX Management
If you are serious about establishing HMI guidelines across a company or beyond a product you very early on need to install an interdepartmental UX Manager responsible for defining and monitoring a design-approval process. Different departments will have different points of view regarding the necessity for good UX. One department might strive for better usability and a user centered application, another might only be interested in using a toolbox to develop more efficient software. Combine this with a tough deadline or one department who requests new features drowning out all others, and priority and awareness for UX will drop like leaves in autumn – unless it actually delivers the development efficiency that was hoped for. Still, an effective UX Manager will not eliminate the need for developers who have incorporated UX Design. Quite the contrary: the UX manager must explicitly work on establishing this holistic mindset among his developers.
Right lane or fast lane
Of course, diverging interests cannot be aligned overnight. On the one hand there is the understandable problem of a feature-driven department expecting early results as not to be stalled in their market-driven endeavors. On the other hand the early corporate UX framework with its HMI kit and HMI styleguide must be tested along various scenarios in different departments before it can be used across the company. A bad concept can spread in the same way as a good concept. Referencing unfinished components of the HMI kit in the application code is a high risk at this early stage which may lead departments to implement their own HMI components (not following the design guidelines, as shown in figure 4). The prime need of these developing units is to be independent of the developing speed of the HMI kit team (see figure 5).
Figure 4: Referencing HMI kit templates holds the risk of views breaking after subsequent changes to the kit.
Figure 5: If instead of referencing living code, dead code is cut and copied, there is the danger of not having any consistent design concept.
Evolution promotes Development
This dilemma can be averted by using an evolutionary and continuous approach. We advise our clients to adopt “concept tagging”: as soon as an HMI concept is advanced enough that interaction designers can appreciate which user problem it could solve (not meaning it already solves this problem at that early stage), a globally unique ID (“GUID”) is assigned to the HMI concept. From this moment on the GUID appears in every asset of the concept – whether it is a design guideline, a Photoshop screen, markup, production code or exemplary code. Using a corresponding asset management system it is possible to aggregate a view of the respective concept that shows the developer: “for this user requirement, use these assets and follow these design guidelines”.
Our asset management tool for WPF based on GUID is Centigrade XamlBoard: icons and XAML snippets can be tagged with meta data to facilitate finding and correct use.
Figure 6: Centigrade XamlBoard is an asset management system with which icons and XAML resources can be equipped with meta data like usage information.
Also, there are many design guideline assets already in existence that can be integrated into the overall picture – Apple’s iOS Human Interface Guidelines or the Google Material Design Guidelines just to mention some of them.
Figure 7: Google’s UX Guidelines (Material Design) und iOS can and should also be consulted depending on the design problem.
Unfinished does not mean unusable
When using concept tagging it is no problem if an HMI kit component is still unfinished or untested. Developers can copy the unfinished code including the GUID and incorporate it into their own infrastructure, using their own approach at their own speed. In regular intervals a code difference analysis is conducted to show how a concept has been solved by different departments. The concept is consolidated or substituted by the HMI kit team in case the HMI kit’s version has been finished in the meantime. In return the software development teams’ solutions and strategies are integrated into the HMI kit to improve it for other departments. Speaking in terms of evolution theory the GUID serves as the mutual DNA for related assets being reproduced based on the same concept cell (see figure 8).
Figure 8: Solving the dilemma through concept tagging – individual concepts and their corresponding code fragments are equipped with GUIDs, making them retractable and consolable in the future.
Conclusion
The HMI styleguide is one part of a larger corporate UX framework for a consistent HMI. Being controlled top-down but advanced bottom-up, user requirements are continuously collected and possible solutions tagged with a unique ID. Design guidelines, code templates and reusable HMI kit components can be improved in an evolutionary way, being retraceable and changeable at a future time – and making it clear which asset should be used in an individual use case to create a consistent, aesthetic and intuitive HMI.
This was part two of “Establishing an HMI Styleguide in a Company”. Read part one here.
If you should be interested in getting our support for your project feel free to visit our services pages:
