Designing a fully customisable marketing website
I designed a component-based website for Rosetta AI and modelled the content in Prismic to allow for a great deal of customisation thanks to Prismic's slices technology, resulting in countless hours saved on design and engineering resources, by allowing the marketing team to quickly make changes, add new pages and content whilst still keeping the site visually and functionally consistent.
Requirement:
Design and plan a website that matches the Rosetta's fashion focused brand, and a website that can be fully customised by the marketing team without the need for a design or engineering implementation.
Final product:
Designed a component-based website for Rosetta and modelled the content in Prismic to allow for a great deal of customisation thanks to Prismic's slices technology.
The result"
Countless hours saved on design and engineering resources, with the marketing team being able to quickly make changes, add landing pages and more whilst still keeping the site visually and functionally consistent.
Iteration:
A different approach to web design: component-based design
The brief for the site was a little different than usual, while usually I would start with mapping out the information architecture, then move onto content strategy and wireframes, this time I had to create a website that had to fulfil requirements that were not yet known.
In order to do this, I decided to start with components first, and design a large number of components taken from the familiar patterns and use cases from the web and then put the pieces together.
I started by creating a base number of pages, which would then go to become "custom pages" in the Prismic content model.
The base pages were the "homepage" and the "pricing page" which are single type pages, which means there can only be one of each. Then a number of repeatable pages that can be re-used and re-created at wish, these were the "feature page", "resource page, "landing page" and a few more.
Once these have been decided and discussed, I started mapping out the components that will go into these pages.
I have created over 20 components, with lots of customisable options, from different layouts, to different background colours.
Now it was time to design the components.
The main inspiration for the site visual patterns were Apple's Human Interface Guidelines, a simple and sure-fire way to create and interface that is consistent and pleasing to eye.
Once the components (which I'm gonna start calling "slices" going forward to match Prismic's own terminology) were mapped out and the base elements designed, I have created different variants for background colour, layout as well s for the different breakpoints.
I have used a total of 4 breakpoints (mobile, tablet, desktop, large desktop) so if a designer wanted to put together a page before doing it within Prismic they could do it easily and quickly in Figma first.
Once the slices were completed it was time to go through approval and revision stages.
I've also created a couple of pages as an example to show stakeholders on how a finished page is supposed to look like.
The approval marked the end of the design phase. Next step was the content modelling phase, which is another Prismic term for data modelling within the platform.
Content modelling within Prismic
The Prismic interface and mental models are pretty straightforward and probably one of the easiest Content Management Systems to use.
I have setup the base pages following the site structure, and then proceeded onto creating the "slices"
I have added certain limitations depending on which slices should or should not be included in a specific page type, as well as added limitations around the design itself, to keep the design consistent in all possible scenarios.
Once that was completed, I have filled all the content from the previous website version and proceeded to document the work on Loom.
Once this was all complete, the designs and the content model was handed over to the developer.
The impact
The website looks slick, but more importantly thanks to the simplified workflow and to the ability given to the marketing team to make changes on the go, create new pages on a whiff, the speed of execution has drastically increased from 1 week of work to create one page, to a couple of hours at worst.
Creating a design system from scratch
A good component library and design system are fundamental to improve speed of execution allow teams to iterate through ideas and hypotheses much faster compared to the classic workflow where UX and UI are separate.
The first requirement upon joining Rosetta.ai was to create a component library / design system to allow for easier prototyping in design.
A good component library and design system are fundamental to improve speed of execution and allow teams to iterate through ideas and hypotheses much faster compared to the classic workflow where UX and UI are separate.
UX designers can now build up wireframes with existing components while UI designers only work on maintaining the system and managing handover with developers.
The first step is to take an existing base library whose look and feel is closer to our brand.
The development team has been using ChakraUI in development so we took that as a base and started building on top.
You may ask, why not just use ChakraUI then? Well, those libraries are extensive and decently thorough but they are also fixed and harder to personalise down the line. While the styling of the components can be changed it requires work on top of these components which will create bloated code and will likely decrease productivity, therefore going against one of the main principles of building a design system: speed of execution.
Open source component libraries are a good resource to use for prototypes or MVPs but once you start building your app, having your own custom components, tailored to your brand, tailored to your use cases and functionalities is fundamental.
Using Atomic Design Principles
First thing to do when creating a design system is to create principles for categorising all the components.
Even if we only have 30 components, if they are nor organised properly it is very easy to get lost or create duplicates.
The best way to organise a component library based on my experience is to use Atomic Design principles by Brad Frost:
The main principle is to divide the components hierarchically, starting from Atoms, to Molecules, to Organisms, to Templates and end up with full Pages.
I have taken a few ChakraUI components and the base html fields needed for a good component library and got to work
The structure
Foundations
The foundations include all of the base elements that each component and atom is going to be made of, these include:
Colours
Includes all the colours that can be used within the system and is sub-divided into four categories:
- Base colours, which are the black and white shades and tints adjusted to the main brand colour.
- Brand colours, which are the main brand colour accents, with shades, tints, muted versions and gradient variations.
- System colours, which are the base green (success), orange (warning), blue (information) and red (errors).
- Graph colours, which are variations of all possible colours that can be used within graphs, adjusted to fit well with the main brand colours.
Typography
Includes all possible text use cases from headings, to links, to single line text, to paragraphs.
Layout Primitives
Which are the base foundation of all containers, boxes, cards and layouts.
These are subdivided into different elevations and different background colours.
Grids
Includes all the grid layouts for every single screen (large desktop, desktop, tablet, mobile and more)
Atoms
These are the building blocks of all interface components and include base HTML elements such as labels, checkboxes, radio buttons, inputs and more.
Molecules
These are components made of two or more atoms, that usually have a specific function. Like a search input with a label, search icon and different states.
Organisms
More complex components that incorporate two or more molecules and can serve more than one specific function. An example of an organism is a header section.
Templates and Pages
These are the final components built with multiple organisms, templates are similar to bare bone pages layouts without imagery and content. Whilst pages are the complete interface design.
The Result:
A component library of 40+ fundamental components which led to increased speed of ideation for the design team and increased speed of execution for the development team.
All while maintaining and promoting brand consistency across the platform.
Building design operations workflows in startups.
Full case study coming soon.
