Small features (those that take less than ~3 hours to create) are usually simple enough that they don’t need any formal design/development process. After the idea has been approved by the Community team, contributors can go ahead and build them in whatever way seems best to them.

Any projects that are larger than that, though, usually benefit from a more intentional approach. This helps to save everyone’s time in the long term, and to avoid situations where key parts of the feature need to be redesigned or refactored after they’ve been reviewed by the Community and Meta teams, which can be demoralizing for everyone.

The process outlined below doesn’t have to be followed rigidly, but it captures the team’s intent, which is to gather detailed feedback (on both design and development) early and often.

  1. Idea
    1. Follow the process for gathering stakeholder input and feedback before moving on to design.
  2. Design
    1. Once the idea has been accepted and iterated on, the design process starts by creating UI wireframes. They don’t have to be pretty (something hand-draw on a napkin is enough), but they should be comprehensive. The act of creating wireframes forces you to think through details that are often overlooked when just talking about an idea.
      1. If you prefer, you can build the raw HTML/CSS instead of wireframes, but try to avoid spending a significant amount of time on things that might change based on stakeholder feedback.
    2. Publish a new post on make/Community asking for feedback on the wireframes. Make sure to describe any user actions, inputs, etc, that weren’t able to be captured visually in the wireframes.
    3. Iterate on the wireframes based on the feedback from the community.
  3. Development
    1. Once the feature has been designed, now you can start writing code. Similar to the design process, it’s helpful to get feedback early and often. The Meta team will need to review and approve any code contributions before they’re merged, and they often request changes (both big and small). You’ll save yourself time and frustration by getting small reviews along the way, rather than a big one after you’ve built everything.
    2. It’s usually helpful to break the project into small components, and work incrementally. One way to do this is with Agile sprints, where each short sprint produces “working software” that can be deployed now, even if it only does something a small piece of the end goal. Use whatever feels best to you, though. Another approach is requesting reviews at key milestones (e.g., 10% completion, 30%, 70%).
    3. When the feature is complete, the Meta team will do a final review, merge the code into the official repository, and deploy it to production.