Challenge
Reference Architectures, support documents and in-product information pages all used different illustrations. These illustration styles had no resemblance to each other. Many of the styles were very outdated. Overly detailed illustrations only complicated user understanding. My team and I set out to create a common visual language that could be used across the aforementioned scenarios.
Approach
We first had to understand the full range of uses. We sat with product architects, technical writers, and the product education team to understand the constraints and challenges they had in producing their deliverables.
After understanding their goals, we started collecting examples of all of these documents. This way we could make sure we get the full scope intentions. We would also redesign some of these documents to demonstrate the value of the new visual language.
An example of one of the old architecture illustrations.
After document collection, we would start brainstorming. We had frequent check-ins with stakeholders so we could rapidly iterate on appropriate ideas and ditch solutions that wouldn't work.
Solution
The teams using this new language would sometimes have design support. But in the most common use case, reference architectures, they would not. Design would be done by the technical writers. With this in mind, we wanted to create something with simple, flexible rules that could be amended by users with limited visual design experience. After we created the language, we would document these guidelines in an internal style guide.
We determined the illustrations, with out text accompaniment, would never be able to convey such abstract concepts as a virtual delivery agent, for example. Any attempt to do so just added noise. Some of the current styles depicted hardware components, but everything runs on hardware—the diagrams started to look like cartoonish depictions of a PC e-commerce site. So we set out to find how the visual language could add value to a potentially complex document like a reference architecture.
We determined the illustrations would be most valuable as an icon for quick recognition for IT administrators who revisit these diagrams often. Users weren't reading these diagrams to understand the components. They were reading to understand the relationship between components. This meant we could create conceptual illustrations as long as they were simple, easy to distinguish and easy to learn after a few views. This simplicity would also keep the iconography from appearing dated.
Grouping had in the past been denoted by drawing squares around multiple components. This saved space, but also made it difficult to distinguish between groups in complex diagrams. Switching the grouping method to circles would provide more whitespace between groups and make them easier to differentiate. The circles were recommended for use in a new digital format in which users could dive deeper into parts of a diagram for more details. Traditional square groupings with updated visual treatments could be used when documents needed to support print format. We suggested some user research to see how many people actually print these diagrams out to determine if print format was needed.
We couldn't create an icon for every component that is ever mentioned in an architectural diagram. Nor did we want to try. Since the new philosophy for visuals was to aid in recognition after learning the symbol, illustrations for components that are only referenced once would be a waste of resources. So we created standards for creating a label for these cases. The goal was to have a language that would speed the writers' workflow up and not have them waiting on a designer to come up with an illustration that will only be used once and serves no purpose other than decoration.
Finally, we retrofitted some of the old reference architectures with the new visual design, created a presentation and sat down with a few stakeholders to go over what we created. They would act as a pilot group so that we could iron out any unforeseen shortcomings and build out the initial icon library.
In the end, stakeholders would have access to a style guide, examples, and a library of commonly used assets. We would offer consultation while the switch was made to the new language.
An example of an architecture diagram using the new visual language.