Workflow

General principles

• Tech, Design and Product need to be separate units, having authority and responsibility over their respective processes, tools and outcomes.

• Internal documentation must be a central concern in a remote project. A writing culture eliminates misunderstandings and allows teams to progress autonomously without reliance on constant back-and-forths.

• Tasks pertaining to a single team (e.g. deployment architecture for Development, branding guidelines for Design) can be managed directly between that team and Product.

• The Design team will be progressively putting together the design principles outlined during feature development into a complete specification of the project's UX and design language.

• The specification of expectations for each step should be clear and documented, and it should be clear for every team what's expected of their output in every stage, as well as clear requirements for each step so that teams don't have to constantly cross-check progress.

Practical steps for QA and review

• When a design or feature is ready for QA or Review, a Github issue is created on the Beabee repository with all the necessary details to inform the review process (screenshots, explainers, other references)

• The Trello card tracking this design/feature is placed on the QA/Review column, and the Github issue link is added to the description.

• All discussion should happen on the Github issue, since Trello's discussion handling is clunky and hard to read and link to. Updates to the designs/features under review also go inside the Github issue as additional comments, so that the progress of each open item can be properly tracked and referred to later.

• Once everything is okayed, the Trello card is moved and the Github issue is closed.

Process

Diagram

• Pink: product owner, UX/UI designer, lead developer

• Orange: UX/UI designer

• Yellow: Lead developer, developer

• Green: Product owner

Steps

• Requirements [Design, Product, Tech] Create a written specification of the feature in Gitbook, agreed by all teams

• Wireframes [Design] Create a practical blueprint of the content structure, disposition of visual elements and ways a person can interact with them

• Wireframe review [Design, Product, Tech] Team reviews wireframes

• Designs [Design] Create a faithful graphic representation of what the frontend should look like and behave (also known as “mockup”)

• Design review [Design, Product, (Tech)] Design and Product review designs. Tech is there to ensure feasibility of implementation but not to feed in on other aspects of the design.

• Tech scoping [Tech] Tech team scopes out what needs to be built to implement the feature, splitting tasks between the backend and frontend and agreeing on implementation details like API design

• Frontend/backend implementation [Tech] Implement the feature!

• QA: Code review [Tech] Code is peer reviewed

• QA: Design and UX review [Design] Design reviews feature and gives feedback on what changes are needed to ensure the feature is faithfully implemented. This can include asking for limited changes to the original design if they think on seeing the implementation there are some improvements to be made (e.g. improving poor UX etc.) but any major changes should be kept for a future feature cycle.

• QA: Requirements review [Product] Product ensures implementation meets the requirements specification

• Final review [Product] Product gets final review before feature is deployed. This review should be based on the requirements and design agreed at the start of the process and not introducing new features or changes.

• Deploy [Tech]

Quality assurance principles

Allocated QA time: 12-2pm German time

• QA needs to happen across the whole project, including development

• QA should be prioritised where possible (especially if the feature aligns with the sprint theme) as it unblocks teammates.

• QA must been done at the latest in the next allocated QA time (but ideally sooner).

• When you move task to QA in the sprint leave a comment: @person who should do the quality assurance.

• If something comes up in the QA that is a blocker for taking something live, we leave a comment @person owning the task and move it back to "To do"

Review principles

• First reviews are done by Julia and Tobi. They decide when it makes sense to bring testers into review stage.

• When something is ready for review, we ping Julia and Tobi in Slack

• Feedback is added in Trello in the following way

  • Single feedback added as a checklist item

  • Checklist items are added numeric

  • The page referred to is added with the link

  • In discussons we refer to the checklist items based on their numbers

  • When item turns out to be irrelevant it gets deleted, otherwise it can get modified by the person taking it on

  • Feedback that is not critical for taking the task live is added to the backlog