Planning Sprints with Figma

Oftentimes, our frontend sprint starts after we receive new Figma design. Before a sprint ends, the figma would be updated to include new designs for features in the next sprint. Hence, it is possible to use Figma as the starting point to understand new business requirements, discover new reusable components and functions, detect pain points and missing parts in the design and plan out tasks and tickets for team in the next sprint.

Targets to complete after reading Figma#

For each new Figma design in a sprint, frontend team should plan at least 1 internal meeting to discuss over the Figma design to complete the following tasks before the new sprint starts:

• Understand business requirements: since the design represents what needs to be implemented for the next sprint, it is frontend team to understand clearly which features of the business logics are covered in each page of the Figma design, and whether the Figma design has covered every features required for the sprint.
• Discover reusable components, styling and functions: there are parts and styling rules that are repeated between pages in a Figma design. Implement and maitain these parts as reusable components, styling and utility functions would not only improve code reusability, but also provide UI consistency between pages and in the application.
• List API endpoints required for the sprint: the Figma design should help team to tell in each page, which API endpoints and services need to be used to complete the implementation of the page. The frontend team then can pass the list to backend team to work on.
• Detect pain points of the sprint: some pages in the sprint might contain complex features, ranging from a new component, an unique animation to a complex multi-page form or page routing. It is beneficial for the team to detect these problems beforehand and have a plan to alocate resources to tackle these features.
• Detect missing parts of the design: a design can lack adequate information and pages to let the team know how to implement all business requirements of the sprint. These missing information should be reported back to the Project Manager as soon as possible in order to ensure completion of the sprint planning.
• Planning and schedule for the next sprint: with all the information and break-down features gathered from the Figma design, the team can then has a good estimation of the workload, assign tasks to each member of the team and propose the draft schedule to the Project Manager for further discussion and monitoring.

Techniques to break down a Figma design#

Following are two recommended methods to deconstruct a Figma design into smaller features and tasks for the team. It is adviced to use both methods in order to break down new design more efficiently:

• Bottom-up: analyse the new design and detect similarity between pages and figure out reusable parts of the application. This is useful to find out general styling rules, new components, and sections to implement. Following questions can be used to guide the discussion:

  • Can the team group font families/font sizes/colors used in the design together in a css/scss file for reusability? (can ignore if the design and implementation use CSS libraries like TailwindCSS)
  • Can the team group adhoc design choices (border radius/margin/padding/shadow) together in a css/scss file (can be ignore if the design and implementation use CSS libraries like TailwindCSS)
  • What are the components used in a Figma page? Which ones are from last sprint and which ones are new? Which components appear in other pages of the sprint?

• Top-down: analyse the new design based on routing and data flow to understand:

  • Where a page is navigated from/Where the page navigates to after user interacts with a button/a form/a link in the page
  • What data a page needs to load to display to user/what data a page needs from user to trigger the next action/navigation.
    • Which endpoint(s) the page needs to call to load, and its input/output data?
    • Which endpoint(s) the page needs to call to respond to user interaction, and its input/output data?

  This technique is useful to break down business logic and collect information about routing, API data and flow of the application.