One of the major tasks ANZ has taken in recent time is to uplift the much dated Android goMoney mobile UI to a more modern and sophisticated design. The design direction is largely influenced by Google Material guidelines. We believe it is a visual language that synthesizes the classic principles of good design with the innovation of technology.
I am the primary point person for our product design standards & guidelines, ensuring consistency, scalability, and modernity of elements and patterns. Determine appropriate use of patterns as well as when to evolve them or leave them behind entirely. (while updating our style guide and documentation accordingly).
With the establishment of a design system, product design simply becomes a matter of combining our established templates and components, much like lego bricks. This frees us to focus on user experience, problem solving, and building meaningful experiences.
Design challenges:
Structure
Process
Whenever there is a new screen that needs to be built, the screen will be assigned to a design template. A design template can comprised of different design components. The business analyst will create a story for the developers along with detailed explanation of the design specs and interaction prepared by a designer.
Templates & Components
The objective of our new design setup is to have a modular approach that subdivides a screen (template) into smaller parts (components). The components can be then be independently created and then used on different screens.
We concept, apply, stress test all the components across multiple edge cases and scenarios and iterate on them to make sure we have a robust, flexible and future proof UI patterns.
Challenge: To have a UI pattern that will cater for all edge cases require deep understanding on the behavior, interaction and user flow of an existing feature within the product. It isn't well captured within ANZ, hence a lot of times, it is about working extremely close with BA and testers to figure that out.
Retrospective
Using Photoshop for UI design isn't the most ideal tool. However due to the slow procurement process within the organization and the fact that ANZ needs to liaise with many other design vendors that are still using Photoshop, has forced us to stay with Photoshop.
There is an article about creating the design in @1x as the standard process. I concur with the points listed. It is a much better approach and the author has the luxury of using Sketch.
However if you are designing in @2x (.PSD), this should be the approach:
The design team over at ANZ is now looking at migrating over to Sketch at some point. Winning!
Building blocks
Colours
The app has a bad history of designing by 100 designers who come and go with everyone giving different design inputs and direction. Hence this has resulted the app having "50 shades of greys". We have looked at reducing the amount of colors to the essential part. Colours that are also aligned to different channels and the ANZ brand.
Text and background colours
Given that ANZ goMoney app largely been designed on either a white background or a blue background. We have derived a strategy to have text displayed with different degrees of opacity depends on whether your background is white or blue.
Colour choice rationales:
Typography
For Android, we are using Roboto as the design font. ANZ brand font is Myriad Pro however we are still sticking with OS native fonts for both iOS and Android for time being. One of the strongest rationale being iOS's system font comes with Dynamic Type and the dev team is already using built-in iOS text styles.
When it comes to visual regression testing, we are not aiming for a pixel perfect translation from design to build as we know that is impossible. What we are looking for is a build that is close to the design intention. Within the design specs, we do take into account of the top and bottom padding of a font size.
Since we are supporting only English letters (Latin scripts). We are comfortable with applying setIncludeFontPadding() to false to trim off some extra padding in a text view.
Leading & Tracking
We try to simulate leading and tracking in our typography with API like setLineSpacing() and setLetterSpacing(). In testing, setLetterSpacing() is a tricky attribute and hasn't resulted in an ideal output. Hence we have parked that aside for now.
For iOS:
iOS has an advantage in this aspect given that they have Dynamic Type (if you choose to use the system font, which we do). It will automatically adjusts tracking and leading for every font size. Another awesome thing about system font in iOS is that it automatically reacts to accessibility features, such as when bold text is enabled.
Font bounding box
With our design, all UI are designed and arranged according to the text's cap height and baseline.
By default, each font comes with some extra top and bottom padding to cater for different characters and glyphs. We have listed out the padding spacing in font sizes that are used in the app. Below is the list of top/bottom padding for each font size after we applied setIncludeFontPadding() to false.
Design to build translation
Retrospective
Taken accessibility into consideration, as the user scales the font size in system settings, the intrinsic padding within a text view will increase as well. Hence the top/bottom padding within a text view has to be calculated dynamically.
So probably, we shouldn't be exerting too much visual control over how typography presented itself on screen?
Setting includeFontPadding() to false will only work great for Latin fonts. If we are going to start support non-Latin scripts, this will not work properly. Instead get the Font Metrics Object from the text view will be a better approach. With that, we can query different attributes on that font metric. With that font metric, we can get information such as where the descender line is.
For developers who want a more precise control over alignment and placement. Look at Google I/O 2016: Designer & developer communication video. It has an interesting solution for this.
Components
Templates
Confluence
We have begun to document all our design specifications on to Confluence. This is the source of truth. We made that decision as Confluence it the medium within ANZ that everyone has access to. Everyone will be able to contribute to it.
Retrospective
Generating design specifications manually is a pain. If we were to successfully migrate over to Sketch. We will be looking at using plugins like Measure https://github.com/utom/sketch-measure or Craft library https://www.invisionapp.com/craft to generate styleguides for us.
Challenge: However introducing 3rd party cloud services, eg: Dropbox, Adobe CC Library, etc are super tedious and arduous due to the strict IT policy in a banking environment.
Retro
We had a retro session to go through what went well and what went wrong in this particular release. Notes were documented on to Confluence for future reference.