Design system decoupled from CMS, but easy to integrate with any through data transformation layer - to mitigate CMS-related risk and increase the value added by the DS
Documentation & Versioning agreed
Testing: Unit testing, Visual Regression & Accessibility testing to be included
Pull Requests Review: for small stuff: 1 pull request, for bigger stuff: 10 separate pull request - RB can guarantee 2 days SLA for Pull Request Review, but given the top priority of the design system, the team will try to keep the same day review
Documentation/coding standards should become the part of the design system to make it future-proof for any new people working with it
All meetings around the component decisions (the ones with Nathan McKean) should include also @... , @... & @... from RB end
QA activities should be performed conjointly with Reckitt IT (DA needs to discuss use cases with RB. RB needs to review and finalize them)
All parties have confirmed that all browsers will be covered within the scope
There is no contingency in the submitted estimate. Small contingency is acceptable
‘Button’ demo expectations were not satisfied - component development is done based on standard project structure and in connection with Contentful for Demo purposes. Final Button component will be re-worked to meet new requirements and tech stack (Storybook, Changeset, AWSCodeArtifact, etc.), identified during Discovery phase. Thus, it was agreed with @... that review of the Button component will be done in the next phase as the current one will still be changed and other is no sense in checking it right now.
Tech teams are aligned on further steps regarding MVP development and there are no objections from @... and @... to move forward with Hero Teaser PoC phase
Agenda for daily stand ups should be provided, when specific issues need to be discussed. Flag for @... presence is required (as well for the other major stakeholder)
Workflow for the MVP phase will be set up the nearest time
Technical sessions will be scheduled. Opened issues: CSS / HTML issue, Contentstack usage
Deliverables' quality is important. We need to agree the control points to add transparency
All the occurred for the moment gaps should be highlighted and added to the risks if required
QA from RB is assigned. WoW will be set up the nearest time
UAT can be performed starting from the 26-27th of May by @Lewczuk, Katarzyna
Visual regression testing is totally depending on tool selected and on its limitations (Percy tool is proposed for the moment). Not to reduce the testing productivity we can implement testing only on deman
Small strategy for Percy tool usage can be developed to meet with existing limitations
We need to clarify how performance should be evaluated for Design system outputs
Risks’ list from testing perspective should be provided. Risks from business perspective can be found here
We need to agree which Accessibility standards should be used. For the moment there is one initial version - https://rb-digital.atlassian.net/wiki/spaces/DS/pages/46129774610 , we shall take into account WCAG 2.1AA and we shall meet the accessibility criteria in accordance with the policy prepared by Sarah Leech (attached)
There should be separate team to use and test the components on production
For the moment it’s an issue how to check accessibility & performance for all components' combinations. We can cover it for some Page templates, as an example, to define the procedure
There is a technical risk that after components' combination new bugs can occur
Proposed addon for Storybook is experimental one - it also should be added into the risks' list
Additional technical risks will be defined in course of UAT
Success criteria should be added to components as a response to the brief and they should be confirmed. We are adding them into JIRA for @Lewczuk, Katarzyna to access them easily, but I guess we should start from Confluence and confirm them with Nathan first as a next step after Component kick-off, followed by internal interface discussion.
To include Nathan into Component Interface discussion in addition to Tech team. @Mckean, Nathan we have an agreement with Tech team about PR review (including interfaces with props) and it is like 48 hours, so your review should also be aligned with it.
Design system components are developed in the same repository as other components developed by the tech team, though the DataArt team used a separate Storybook for the design system.
The Storybook content can be updated through committing changes to the repository, not through direct editing, which makes updating the content a bit more complicated.
If we want to make updating the content less complicated we should start looking for another tool (e.g. Zeroheight) as a document storage.
We definitely want to make document storage less fragmented so that we could keep the documentation in one place.
Earlier we agreed to have at least one component developed E2E. To this end we need to have clearly defined success criteria for a component so we could test it.
We don't need it right now, but how are we going to address version control?
The transformation for an imaged wrapped in the link is not easily noticeable. The dev team should raise similar cases as early as possible.
Accordion. Transition duration is moved to global tokens. It is set to 0 for now.
Disclosure. There is a slight design deviation for the outline, but we earlier agreed to follow the design for the subtle button for this case.
Page block. The idea behind the page block is that it is used as a building brick for creating sections in page templates.
Carousel. Swiper library was selected to be used for this component. Configuration is still to be discussed with business and acceptance criteria need to be defined and approved.
Page samples. The dev team have built some pages using the coded components.
RB have a big quarterly teams day tomorrow, which takes Nick out for a day and Nathan for a few. Along with some other delays this may affect the timeline. Even still, the dev team we’ll do their best to catch up with the schedule. If not, RB will accept of any variance in the timeline.
It’s more important for RB to queue up Milestone 3 than give feedback on Milestone 1. The DA dev team agree.
Skip to content. We want a little arrow icon next to 'Skip to content';
Inline links and body should always be the same size;
Cards. The current Card implementation is that the whole card is clickable and in addition to that you may have a CTA link within the card, which will be clickable as well like an additional tab stop;
Cards. The link for the whole card is not mandatory;
List. In List component we do not control the size of the cards, but rather the number of cards in a row;