Conceptual Design
In this post, I would like to share one of my older conceptual design project. This fits into my blog series demonstrating my design process as a repeatable and structured activity.
Assignment
The goal of this project was to provide an alternative visual design for existing topology map component. I was able to observe a challenging environment, where the product team was receiving a lot of negative feedback on the existing topology user interface that was all vaguely labelled as "visual style" issues.
As a result, a large number of stakeholder from different teams were proactively attempting to provide their feedback on how to resolve the issue.
Make it bigger. No smaller. Little bluer. It needs a nicer icon. No, no icon at all. Yellow is not yellow enough. Let's change it to vertical alignment. No, wait, it has to be horizontal, but a little smaller. It feels dull. Now it feels busy.
My goal was to not just step in an attempt for a final and polished design. I was aiming to highlight the complexity of the design domain that is involved and rise our mutual understanding of what it takes to design a good data visualisation component. There is very little "random flash of genius" in any data visualisation work. Even that anyone is invited for a design critique and can freely express their opinions and feedback, this work requires a skilled craftsman applying scientifically proven methods and data.
Gestalt Principles
The crucial pattern that I introduced to the team was Gestalt. I explained the concept that is about visual relationships, contrast and similarity, and not about colourful emotions or aesthetics that the team was originally discussing.
The main concept that I applied to the topology map style was Gestalt law of grouping. Our mind understands external stimuli as whole rather than the sum of their parts. When looking at a topology map, our brain tries to understand the meaning of the whole composition as opposite to a common engineering myth of users processing each individual visual attribute in the same way as a software algorithm would.
Visual Semiotics
Visual semiotics or mean-making analysis was related to original iconography. Topology map contained a lot of abstract icons with no clear meaning. Even that we did not have a proper usability testing available, I was highlighting the particular signifier within used symbols and explaining to the team, that there is no way that a human brain will associate the icon of an ice-cream with a database system, even that it looks appealing as a visual style idea.
A clear label with appropriate use of modern typography that supports correct visual hierarchy can sometimes do the job better than any other abstract symbol.
Accessibility
Approximately 4.5% of the entire population is colour blind of which most are men. Some people think that the colour blind don’t see any colours at all. Although this can be the case, it’s very rare. Most colour blind users are less sensitive or completely insensitive to either red or green colours.
Visual Attributes
Because of the existing technological constraints, the data that the component should display were already defined and this concept was focused only on the visual representation.
In the initial phase, I mapped the data to visual attributes that humans are good at translating into qualitative meaning.
Design Framework
Once I have the visual attributes defined, I created an initial grid layout for the component map element. I deliberately worked in black and white mode and only added colour as an attribute, never as a decorative or styling element. I immediately realise that there is just too much data and too many visual attributes for a human to process.
Interaction Design
The final visual design had to take into account all the possible interaction states. The element needed to respond to a particular zoom factor and screen size, but also to a number of other interaction states — normal, hover, active etc.
Conclusions
When a certain aspect of the user interface does now perform as expected, one of the possible reactions is that a large number of internal stakeholders is attempting to "help" and provide their feedback and input. In most cases, this is only targeting a visual style and the skin of the whole problem.
The resulting design process is ineffective, often lacking both real user data coming from usability testing and UX Design craft such as Gestalt, Semiotics and others. One of the possible reasons is that engineering driven teams have a perception of UI data visualisation being a subjective art.
It is a role of the designer working in a large enterprise to raise the knowledge bar and constantly explain all the skills and methods that went into the design decisions and at the same time demonstrate the designer's competence. As a result, the mutual trust will rise and even that the final design might not incorporate all the individual opinions, the team has the confidence that they get the best possible output within existing constraints.
