So, what is the framework?
The Aviva Front-end Framework is a shared global UI pattern and Front-end CSS / HTML code base which provides a consistent global experience for our customers.
The Front-end Framework is an atomic UI library. Those familiar with the Atomic Design principle will understand that this means the Framework UI is a collection of individual atomic elements (form labels, inputs, buttons) which combine together to form molecules (cards, search field). These molecules can combine further to form complex organisms (global nav).
In the future, the Front-end Framework will include page templates as guidance for all on padding rules. This will ensure consistency across global markets furthermore.
As a living library, we seek new requirements, suggestions, and ideas that best cater to our customer’s needs. With everyone feeding into the Framework it will ensure it continues to grow and become as well rounded as possible to cater for our diverse portfolio.
OK, how do I use the Framework?
If you are new to the Framework or need a reminder on how to use it, please read through the detail below:
Firstly, which version of the Front-end Framework does your project use?
When discussing a project, check with your Digital Product Owner which version of the Framework the consuming development platform is using as this will dictate which version of the Framework you use ie. v.2.0.0, v3.1.0 etc. If there is any confusion, you can check page by page for your project by using the Framework version finder.
This is an important starting point to avoid using the wrong version of the Framework and creating the need to re-work.
Please note, all new components are only ever added to the latest version of the Framework and not retrofitted to the older versions of the Framework.
You can find the latest version of the Framework Sketch UI and release log. This page also includes previous Framework releases. Older Framework Sketch UI is only retrievable as far back as v.2.0.0. Should you need detail contained within older versions of the Framework please contact the Framework team.
Can your requirement be developed by the Framework team or not?
Each updated version of the Framework is released quarterly, so, it is important to speak with the Framework team to find out if your need can be built by the Framework development team and released within your project timeline.
If your need falls outside of a Framework release, you will need to engage with your project's local development team to build in the first instance for your project.
If your need is built locally we ask for that same need to be submitted as a ticket to the Framework team Kanban board to become part of future Framework releases for all global markets.
In order for new components to be included in the Framework, it needs to be scalable and re-usable for global markets. The Framework team ensures other global markets have a customer need for new components.
Project designer or Framework designer. Who does what?
During this process, discuss with the Framework design team to ensure consistency with the other Framework UI patterns that exist and to start defining the use notes of the component.
Once your project need is completed, the Framework designer role begins. They will design the array of edge cases, stress test against global needs, ensure consistency and scalability are upheld and finalise the use notes. This ensures the component is fit for global consumption and re-use once added to the Framework.
Need to add or evolve a component of the Framework. Here’s how
If the Framework doesn’t cater to your project needs you can evolve an existing component or create a new design. Here's how:
2. Discuss with the Framework design team to capture any early considerations. The earlier the better to avoid any re-work or breaking Framework code changes. The Framework design team will focus on global re-use of your need where possible. Please note that components within the Framework can be altered through code rather than evolving the component from the ground up. A quick conversation with the Framework team will help here.
3. Evolve the component to a finalised state and get project sign off with your Digital Product Owner and Project Design Leads as normal.
4. When submitting new or evolved requirements to the Framework design team, please read through the ‘How to provide a new component’ checklist to ensure due diligence is taken.
5. Submit a Jira ticket to the Framework team Kanban board. This is then picked up by the Framework design team and discussed further with the ticket owner.
6. The Framework design team then consider if the request has global re-use and whether or not it is added to the Framework backlog to be built. Should your need not have enough global re-use it will remain a market-specific feature.
There you have it, all done
Once your need has been played through a Framework development sprint it will then be added to the Framework code base and master Framework UI Sketch file for future releases of the Framework. Each global market can then access the new components or functionality.
The Framework team sends out a monthly email capturing all the updates from that month's development sprints. This allows everyone timely exposure to new or evolved components and features they will have access to soon.
Lastly, what the Framework doesn't do!
The framework does a lot of things but it doesn't tell you where to place atoms, molecules or organisms within your design or dictate how to layout your page. That is the role of the designer. If you are ever unsure of the behaviour or use of a component, refer to the detail provided per item on the Framework website.
If you don’t find your answer or the detail you require then ask the Framework design team.
For design, technical or project assistance.
Let us know how we can help you
For further information about the front-end framework, please contact the team members listed below:
UX Design Team
UX Designer Lead - Ronan Sprake
UX Designer - Elliot Goldblatt
UX Designer - Zara Nowell
Visual Design Team
Visual Design Lead - Tom Smith
Visual Designer - Al Grehan
Visual Designer - Toby Haynes
Visual Designer - Kapil Sharma
Visual Designer - Long Chung
Technical Authority - Matthew Squirrell
Lead Front-end Developer - Nicky Bliss
Front-end Developer - Nik Davy
Front-end Developer - Steve Harvey
Front-end Developer - Alex Haines
Tester - Bob James
Senior digital project manager - Robin Magson