CICS is an IBM Mainframe product part of the IBM Z family, which has been providing online transaction management and connectivity since 1968. Currently, 8 out of 10 of the biggest banks and 10 out of 10 of the biggest insurance companies in the world run their applications on CICS. That comes down to an estimate of around 2.1 million transactions per second that constantly run on CICS.
For the 49 years of its life, it has gone through many technological transformations. With its new CICS V5.4 release, it is evolving from being communicated as just a transaction server to becoming a full-formed multi-language application hosting server. The shift in the way we communicate CICS also required this to be reflected in the visual language of the product.
In recent years both CICS and IBM Z as a whole have been facing issues with attracting new talents to progress the technology further, because of their complexity and legacy. Due to the changes and expansion of the tech that has accumulated through the decades of the product's existence, it has come down to a steep learning curve that is often discouraging to young developers. However, new talent is required, as the more experienced specialists are coming to an age of retirement, yet the software is of critical importance and its maintenance and development need to be furthered.
In terms of the visual style guide, we came down to working with two quite polar groups of stakeholders. We wanted to create a language, which feels contemporary, but not trendy, and that can be recognised as appealing to the group of Anettes, who are the new developers and the future of the product.
On the other side, we have the Alans, who have dedicated their career to the development of the IBM Z software and have a tight emotional connection to how it has progressed over the decades. As much as they would like to see new talent flow into CICS, not building upon their legacy and their perception of the software would be disrespectful to the years of hard work they have put into it.
After making an audit of the visuals used in social media, internal and external communication, it quickly became apparent that consistency was lacking, due to the many parties involved in the communication on different levels. The diagrams we had been using to explain concepts in the Knowledge Centre and Developer Centre also lacked a common visual language. That was hindering users from quickly grasping the depicted concepts or seeing the different elements and understanding the main point of the diagram.
An important stage of the visual identity design was trying to pin down what CICS actually was. We listed a number of keywords and carefully selecting those that together represented the software's strengths in closest proximity. The keyword selection was discussed with our OM and marketing department, which meant a broader agreement on the meaning of CICS. This helped us explore and understand what the core of the brand and gave direction for the visuals. Quickly it came clear there was a difficulty in explaining the concept “CICS” to external people, because of the abstract nature of the product. It was difficult to undertake a direction of literally representing it, so out two options were to create an abstract interpretation or an unrelated symbol in the style of GitHub’s octocat, for example. We took the first approach, as it fits better with z Systems' portfolio.
The colours were determined based on the ongoing initiative of creating a z Systems style guide, where blue was chosen as a primary colour. We built upon that by adding orange, which had become a recognisable colour for CICS due to the previously used visuals.
The rest of the visual identity development process involved listing and pinning down problem areas in the creation of visual assets. We created the following sets of resources:
It is common practice among teams to build style guide websites. However, the purpose of those websites is to show the look and feel of a given product and is aimed mostly at other designers. The problem we had was to provide help and resources to teams outside design, i.e. development, marketing and information development. This is why we decided that GitHub and Box would be more appropriate places to host the content. The benefit of having them on GitHub was that users could raise issues, if they find any problems with the files or need a specific resource to be extended, e.g. if they need icons, which have not yet been included in the set.
The project is to be rolled out with the coming of Interconnect 2017. It was recently presented to part of the team and we have begun collecting responses and feedback from its initial actual use.