With the initial stages complete, identifying issues with the PPA system, designing persona’s, establishing the key issues which needed to be addressed and sketching of prototypes. It was then possible to progress onto the establishment of a design language which could be used as part of a design system.
A design system is a collection of well-defined components developed using standards and can be combined in various configurations or patterns to build numerous applications. The components should be easily reusable, guided by clear standards, and can be assembled together to build any number of applications (Fanguy, 2017). Or as Brad Frost describes it in his book Atomic Design, it is a system consisting of five stages shown in figure 1.
- Atoms = Basic HTML elements
- Molecules = Groups of UI elements functioning together
- Organisms = Complex UI components composed of groups of molecules
- Templates = Page-level objects, place components into a layout and articulate the design’s underlying content structure.
- Pages = specific instances of templates that show what a UI looks like with real representative content in place
Whatever the definition, a design system should create consistency by removing friction. By having a repeatable process it should ensure smooth, efficient, and predictable progress, while also improving the quality and consistency of work.(Suarez et al., 2018).
What’s the main Goal
To begin with, the main goal was to apply a design system to the PPA application and redesign it with a mobile-first approach, with accessibility in mind. To an extent, this worked fine for the very early sketching. After completing a fair amount of reading and reviewing various design systems, in particular, Google Material, IBM carbon and Microsoft’s Fabric. I began to release that the end goal was less about getting to the finish line and more about ‘What’, ‘How’ and ‘Why’…(although the finish is always looming).
- What – are the overarching principles that are being applied
- How – can these principles be applied to support the end goal/s
- Why – why are they being applied in the manner they are
In particular, the recently published book ‘Design Systems’ by Kholmatova A (2017), helped inform, clarify and cement the idea of what a design system is and how to go about building and implementing one.
Although they had not been fully defined from the very start the overarching principles had existed in a very nebulous format, easy to use & clarity of purpose. After much grappling with what exactly overarching principles meant and how they could be constructively applied and understood, a set of definitions were arrived at. Firstly the user personas goals were condensed to key goals/points.
|Primary Persona Goals||Secondary Persona Goals||Key Goals|
|Get a clear overview of the status of all requirements.||Wants to be able to stay on top of updating requirements||Easy to see information & informs.|
|Wants staff to update requirements in a timely manner.||Wants to be able to see clearly the status of requirements.||Clear indicators & overview|
|Needs to be to check dates quickly in tracker and update as needed.||Want to spend less time doing admin and working out how PPA works.||Quick & easy use, easy to understand.|
Table 1: Refined user goals
From these goals the key principles where created, and are ranked in order of importance in Table 2. These were informed not only by the persona’s goals but also my own frustrations with using PPA and are also greatly influenced by both Brad Frosts Atomic Design approach as well as Kholmatova A (2017). Although from the industrial revolution, the famous inventor James Watt also provided some excellent guiding principles when he created one of his is earliest inventions, the desktop copying machine (fig 2). When writing the instruction manually he not only made it extremely basic but also stuck the instructions to the actual machine. James Watt made the information findable, clear and best of all got out of the way of the user by ensuring they know what to do next.
|Visibly Informative||Users should be able to see at a glance, relevant and important information, such as status and missing information.|
|Simple & Easy to Use||The system should be self-explanatory with a low learning curve.|
|Helpful||Where possible the system should make suggestions and prevent unintended outcomes, at all times it should not get in the way.|
Table 2: Key Principles
Mood and Tone
Before looking at a design language I decided to try and establish a mood and tone of voice for the application. Given it is an application used within Revenue for the very functional and administrative task of managing requirements and releases I felt a formal tone was needed. Not just because of the domain of use, but also due to the fact that the tasks are quite utilitarian. Although this might mean a look and feel that was probably quite harsh, it did not mean that the application could not adopt a friendly and informative stance and fulfil the key principles already defined.
Looking at some similar tools on the market such as Jira, Huddle and Spira (fig 3) I felt that these were quite complex and technical for what was needed and were probably better suited to experts rather users who use the system once a week. They are also the opposite of the second and third principles.
An area that did appeal to me was that of airline tickets and flight information (fig 4) as well as data visualisation, (thanks to an Easter trip to Norway). I felt these domains are similar to PPA and quite utilitarian in there tone and mood and in some cases had to present similar information such as flight and ticket information but without an edit function. What they did have in common with PPA was a need to present data quickly and clearly and at times while on the move.
For the colour palette, I decided to stick with Revenues own recently established guidelines for use of colour (fig 5).
I looked at a total of four design systems Google Material, IBM Carbon, Microsoft Fabric and Revenues own design system, in conjunction with a large amount of reading explaining what a design system is and how to go about implementing one. Alla Kholmatova’s book ‘Design Systems (2017) I found particularly informative as it got behind the rationale for the use of design systems, and as previously discussed led to the creation of the key principles. It explained how the purpose and ethos of the project are extremely important, as all other decisions are derived from these. It also made it abundantly clear that these principles are something that are not defined overnight and require many iterations and the involvement of stakeholders. Even though this was something I did not have the time for I felt it was a worthwhile exercise in a limited form.
The use of patterns and how they are used to make up a design system initially was poorly understood by myself. and did not sink in at a deep level until reading Brad Frosts ‘Atomic Design’ (2018). His use of chemistry and molecules as a metaphor for how patterns are constructed helped provide a deeper understanding as to how individual UI elements go to make up a pattern such as a search form (fig6). The three molecular elements label, input and button make the complete pattern. Because the patterns provided are already cross-browser tested, time can be spent on more important tasks rather than testing.
Kholmatova (2017) goes even further calling patterns the concrete realisation of design principles and…
“..the physical embodiment of the behaviour we are trying to encourage or enable in an interface.”
She suggests that patterns can be subdivided into functional patterns, the tangible building blocks of the interface and perceptual patterns, the tone of voice, colour, typography, textures, imagery, that which express a brand or feeling.
A pattern library provides a collection of reusable design patterns which have been fully tested, can be updated relatively easily and address common design problems. They also prevent modules being created where ones already exist (Kholmatova, 2017).
System of Choice
From the four design systems, I chose Microsoft fabric based on the following reasoning. I had already established that the tone of voice should be reasonably formal due to the utilitarian nature of the tasks needing to be performed, this is not an application that people want to spend time in. It is used for a very specific set of tasks which are performed because they have to be, as per Revenue governance. Although Google Material was the first system I looked at and spent some time with, and even though my gut said to use it, I decided against it. Mainly due to its informal and playful stance.
I decided against implementing Revenues design system as it is not fully formed and poorly documented, also I felt adopting one of the large better-established design systems would be more beneficial from a learning perspective.
This left Microsoft Fabric and IBM Carbon. Either of these design systems would have been an adequate choice. Both have quite an authoritative and no-nonsense minimalist feel. Carbon did appear to provide better documentation and a larger selection of patterns.
In the end, I opted for MS Fabric (fig 9), as IBM carbon seemed to lean heavily towards sketch for software implementation, an application I wasn’t using due to it being only available for Apple OS. Secondly, because Revenue is deploying MS Sharepoint, which uses MS Fabric, I thought it would be a good opportunity to become familiar with it.
MS Fabric Implementation
As pointed out by Suarez, Jina, Sylor-Miller, Mounter, & Stanfield, (2018) in the Invison Design Systems Handbook, a design system is living, meaning it will require ongoing maintenance and improvements as needs arise. And MS Fabric lived up to this from the start. There where various patterns which the system did not address. This required that they be built from scratch using existing components, which as described by Brad frost is exactly how pattern creation should occur. The first of these being the calendar date picker.
MS Fabric does not define an actual date input with an icon and relies instead on a basic input. I felt this would not be suitable as it was poor affordance and did not conform to the 2nd and 3rd principles “Simple & Easy to Use, Helpful”. The first step I took was to define the actual icon itself, (as per Atomic design guidelines). Although MS Fabric provides a set of icons it does not define the actual touch area and padding for these. So I first defined this for all icons including one custom icon (fig 10). I used an 8 based system ensuring the touch area was sufficiently large (50 x 48 px) as per industry standard guidelines (Apple, n.d.; Google, n.d.; BBC, n.d.)
After the icons had been probably defined I applied the calendar icon to an existing input. Again MS Fabric does not define what the measurements are for the padding between elements so I once again used the 8 based system ensuring there was sufficient spacing between labels, inputs, icons and error messages. Figure 11 shows the first and second iterations of the calendar picker. In the second I enlarged the size of the calendar icon for increased visibility.
Finally, the calendar picker itself (fig 12) which is provided by MS fabric was not suitable from an accessibility point of view. The small labels and touch areas would make it nearly impossible for the primary persona to use. I felt it would better to design one from scratch. Before doing this I created a mood board for the various calendar functionality options available (fig 13).
The various iterations of the of the calendar can be seen in Fig 14. I opted for the scrollable wheel similar to Apple OS, I could find little in the way of supporting documentation to back up this decision, but considering its a default pattern for Apple devices I assumed it would be a good choice. Also, the large clickable date areas and the fact date values can be accessed by swiping the thumb up and or down fulfilled all three principles Visibly Informative, Simple & Easy to Use, Helpful.
The main menu was also outside what was available in the MS Fabric design system. The first step was to create the button which would sit within the header and allow the menu to be activated (fig 15). Again I initially unintentionally broke with the design system and created a button whos font was too heavy compared to other font usages throughout the system, you can see this is figure 15, first image. As well this the hamburger icon had been given a heavier weight to match the font, further breaking from the design system and how it treats icons. This was corrected in the second iteration and the button was brought into line with the overall design system
The main menu (fig 17) itself again used the 8 based system to layout the font and applying padding to buttons, the final colours used are selected from the Revenue colour palette. I made a similar mistake with the weight of the font for the close button but rectified this in later iterations. The font size toggle button and settings buttons where added as late additions. In the final version, a toggle button was used for the font size as I wanted users to able to switch easily to a bigger font size without having to drill down to find it. I envisaged only the two font sizes being needed due to the fact that the default font is quite large, to begin with, 16pt minimum. The settings button would be used for any needed additional settings such the being able to turn back on the beginner help informational panels.
Status Information Panel
Some other areas which needed to be created from scratch where the likes of headings and information panels. The status information panels were of particular importance as they addressed both the primary and secondary personas needs of wanting to have a clear overview of the status of all requirements. In total there were four iterations.
The first of these (fig 18) was poorly executed and this became very clear during feedback in class. The colours although chosen from the Fabric design system were too weak and did not add any value. If anything they worked against the user by giving the impression the panel was clickable while at the same time breaking from the Revenue colour palette. I had also introduced another type of button in the form of a link without referencing the design system.
For the second and third iteration (fig 19), I went back to design system and began with the 8 base system ensuring all the typography was set within this. I removed the colour and selected one strong colour from the Revenue palette so to make the panels standout but without breaking from the overall colour scheme.
For the final iteration (fig 20) I removed all unnecessary text allowing the panels to be informed by the first and second principles…
- Visibly Informative Users should be able to see at a glance, relevant and important information, such as status and missing information.
- Simple & Easy to Use. The system should be self-explanatory with a low learning curve.
I also took some inspiration from Antoine de Saint-Exupery and his famous quote…
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away…Antoine de Saint-Exupery
The final pattern which needed to be created was for the requirement itself. To begin with, I had designed the requirement screen as being one screen where the user would need to scroll to show the requirements and functional sign off dates (Fig 21). Firstly I felt that I had broke from the core principles by not showing all the data on the screen and forcing the user to scroll up and down it was not “Visibly Informative & Helpful”. Secondarily instead of designing the elements as separate patterns and applying them to the page, I had tried to design everything in one go, as essentially one big pattern.
I realised I needed to go back to the design system and break out the various pieces, the calendar inputs and button I already had covered. But there was still the requirements title, the status indicator and the container for the content itself.
Figure 22 shows the final two iterations before the application of colour. The first attempt did not quite work and it took me some time to realise that this was once again due to breaking from the design system. I had introduced tabs with heavy shadowing as well as a status indicator, neither of which existed in the design system. And neither of which had been designed as a pattern. In the second iteration, I considerably reduced the shadow effect and toned down the use of grey making the elements appear more cohesive. I also went back to the design system for the status indicator and set it and the inputs to the full width of the available area including padding.
Unfortunately, I made the same mistake with the title and broke from the design system, designing it as part of the page. On returning to the design system and breaking this out as its own pattern it took on a more balanced layout. I also changed the colour to just one as the decision to use two was arbitrary, I was also bearing in mind Antoine de Saint-Exupery’s quote of…. nothing left to take away.
Overall I felt that the application of the design system was served well by a large amount of reading which was undertaken. The reading was time-consuming but gave me a deeper knowledge and understanding going forward, there were still mistakes made but this was to be expected. My design skills do need work, but I feel this will come with time.
The next post discusses the application of inclusive design and the approach I took.