When I first started my post graduation role I stumbled around internal documents searching for a style guide. The closest I came to was a 2 year old PDF that contained typography ideals and a colour palette for the marketing site.
As I familiarised myself with the software I would stumble across an array of button styling and inconsistent wording. For example ‘Download PDF’, ‘Download as PDF’, Download to PDF’ and ‘PDF’. It became very clear that there were no standards and each developer had built their own version every time.
Research part one
To confirm my suspicions, I went through the software and took screenshots of all the different components and documented them in a presentation. Below are a few of these to illustrate some findings.
The software had primary buttons of different sizes and all had different css/html.
The secondary buttons again suffered from an array of sizes and ambiguous wording. The image below also shows ‘save’ as a secondary button – was this not meant to be the key thing the user needed to do?
Then there were destructive buttons that quite frankly looked like they were primary buttons. Their similar appearance and emphasis made the negative actions stand out too much.
There were also some strange buttons that colour wise, didn’t fit with anything else. And the strange case of ‘available’ looking like a button but in actual fact was not clickable!
Drop down selectors again showed further inconsistency…
And checkboxes and radio buttons also suffered the same fate, including my pet hate of a single row of radio buttons which makes it hard to distinguish rich radio is for which label.
Research part 2
I was concerned that this was having a detrimental impact on our customers. Not only was wording and styling inconsistent, but so was the layout. On some pages buttons were left aligned, others right aligned. I conducted user testing and it soon became clear that every participant missed the buttons that were right aligned.
In user testing I also discovered that users took between 1 and 5 minutes to hover over icons, trying to decipher what they represented and which would carry out the action they wanted.
Our users were left confused and nervous and I knew things needed to change.
I presented my findings to the design team and they were shocked at the screen capture videos which showed users fumbling around. Especially since these users had accounting knowledge and had all used the software for 2 years plus. If our established users had this difficulty you can only image what it must be like for a new user.
Now the team had acknowledged the problem and were on the same page it was time to brainstorm a solution. After attending Epic and hearing Ben Scott‘s talk on life after style guides at the BBC the design team was inspired to start their own.
We looked at numerous style guides and saw Kiran Matthew‘s as a starting point. Then we brainstormed what things we wanted to include in the guide.
- Guide to Gridset
- Typography overview
- Colour palette
- Icon usage
Next we presented our idea to the product team and gathered requirements form them. It was then decided that we would create a working style guide inside the application with code snippets so that developers could copy and paste when needed, saving them time and giving them confidence that what they were building would not be detrimental to the user.
I aim to write a few posts on the style guide as I start to define rules for each of the components listed above, so that you can gain an insight into the decisions I made.
Let me know if you have any advice for building style guides in the comments!
til next time