Case Study 1:

GRABBING THE REINS FOR UI CONSISTENCY

Case Study 2:

ACCESSIBILITY! …WHERE TO BEGIN??

Objective:

• Gain consistency in my company’s UIs, as our user experience and UI implementations are all over the place. There are inconsistent colors, fonts, patterns, etc… This has to change!

Impact:

• We gained an Interactive that is easily located, used, and referenced.

• A new dynamic used tool that aids in design and development

• A new sandbox to try out fresh designs before integrating with production.

Background:

• At my previous company, we had a real problem regarding consistency in our user interfaces. There were earlier attempts at style guides, but these would regularly be ignored with the passage of time. So, we needed to create something that will stand the test of time as a repository for styles, rules, UI elements and patterns. And, it had to be easily located and have buy-in from developers and management.

Research:

• Developers/Engineers don’t seem to listen to “just a Designer” if management isn’t also on board. 

• We don’t have a definitive style guide / UI kit.

• The style guides we have are in (wiki) docs that nobody can find or use.

• I talked to developers about why they thought there were inconsistencies in our UIs (colors, fonts, patterns)…

• “I can’t find the wiki pages that have our styles”

• “I’m too busy to worry about this, when I have a deadline and just need to make ‘X’ work”

• “I just take the styles (hex codes, fonts, etc.) from our other products.”

• “Our UIs are so complicated that I don’t know which styes to use in different places”

• “We have many UIs from different eras in the company, it’s hard to know which version to emulate.”

Ideation:

• Why was traditional documentation not working in this case?

• What was lacking in a “Wiki” page?

• There are so many wiki pages floating around that “one more” doesn’t seem like enough of an answer.

• How could we break through to developers and prove value to managers?

• How can we make something “future-proof / extensible”?

• Answer: We make an interactive UI kit / style guide built into a working frontend that emulates are existing product line that can be easily used by developers and can be extensible / future-proof.

Process:

A two-pronged approach:

• Create an interactive guide using Angular and PrimeNG (with some inspiration from Material, Carbon, etc.) that contains all Ribbon styles, patterns, and UI rules that is:

• Definitive

• Easily found

• Easily Understood

• Future-Proof

• Educate developers and management on the importance of adhering to these new rules.

• Presentations to mgmnt.

• Talk with different developer groups

• Populate every design doc with link to this new style guide product.

Objective:

• Find the best path towards creating WCAG compliant products and features in a manner that satisfies short term and long-term goals.

Impact:

• A template created that can be used immediately as a proof of concept for web accessibility

• Since we built everything into our style guide / UI kit, we avoided developer confusion on how to integrate into existing products and features.

• An extensible “north star” for UI design and development to use going forward as it keeps improving on accessibility.

Background:

• There was a lot of consternation in the company regarding web accessibility.

• A few of our customers had started demanding that our user interfaces be WCAG compliant.

• We didn’t want to disrupt ongoing development in our existing products and features.

• We didn’t want disparate developmnt teams to come up with their own version of “accessible”.

• The best way forward was unclear.

Research:

• It was difficult to know where to start this work, as some aspects of our UIs were quite old and couldn’t easily be updated.

• We also didn’t want to have different teams going off on their own, trying to “solve” web accessibility for just their own product or feature.

• Luckily, we did have the aid of our customer’s own accessibility research into our products. They had done some accessibility testing of their own, and gave us access to the results.

Ideation:

• There were some starts and stops, as teams were anxious to work on this project. We had to get a handle on this though.

• Having earlier completed our UI kit / Style Guide, I had the idea to pause the work starting on individual products, and use our new style guide for this project.

• I had the idea of.. “Hey, let’s use the style guide!” Instead of doing all the initial work directly on products, we could go through the style guide (which is a Ribbon UI frontend), and make it WCAG compliant.

• This allowed us to have an “accessibility sandbox” to try things out and make mistakes without getting in the weeds with actual products.

Process:

• At this point we dove headfirst into becoming the best accessibility experts we could be within a short time frame.

• We pored over the WCAG specifications, and devoted time to reading articles and watching videos and tutorials on web accessibility, researching every aspect as much as possible.

• I handled the design aspects like contrast ratios, keyboard traversal hierarchy, focus styles, and messaging, while my co-worker handled the dev side (DOM, etc.).

Results + Next Steps:

• Once completed (even though web accessibility is never “done”... It can always get better), our new WCAG compliant tool became the “north star” that the company needed.

• It could be used by developers and designers as they work on new products.

• Also, this could be presented to management as an interactive example of what our new accessible UIs would look and feel like.

• Going forward, this tool should be further scrutinized for other aspects of accessibility and inclusivity, helping the company move towards more accessible and equitable products.