This is a general framework for how our team approaches our work. Depending on the scope of the project, we may use an abbreviated version or add more checkpoints and iterations.

The intake conversation. After a member, client, or team member brings an idea to us, we will sit down together and walk through a few key questions:

1. Do we have time to take on this project? How might it fit into our current schedule?
2. Who are the stakeholders? Who needs to be involved?
3. When does it need to be done? If the deadline is flexible, how long do we think it will take?
4. How will this serve our nonprofit members (and/or client)? Does this project align with our goals and values?
5. Do we have a clear sense of scope and mission for the project or feature? Do we need any more information from the member/client/coworker?

Project planning. If we decide to move forward with an idea, we will work as a team to define the purpose, core features, and timeline for the project. This conversation can involve the key stakeholders, or they can be looped in once the project manifesto/outline has been sketched out.

1. What is the mission statement? For each feature or project, we will identify in one or two sentences what it is all about.
2. Who is it for? We will sketch out user profiles (the complexity of the profiles depends on the type of project) and prioritize those users.
3. What do our key users need? This is the place to start brainstorming features and function.
4. How will we build this? What are the technology limitations/possibilities?
5. Prioritize the features list: What is the minimum viable product? What would be nice to have? What can we discard (or move to future iterations)?

Project summary. From the conversation above, and any additional conversations with stakeholders, we will put together a manifesto of sorts, outlining what a project is all about. When pressed with tough decisions or disagreements during the project, this document can be our lamppost reminding us of the core mission and user needs. A rough document outline:

1. Mission statement: One or two sentences answering what the project is and why we're doing it.
2. User profiles: A couple of sentences about who we're making the feature/project for and why/how they'll use it
3. Stakeholders: List who needs to be looped in throughout the process, and who our point of contact will be when working with members/clients
4. Features list: A general overview of critical and wishful features and how they serve the users' needs.
   • e.g., "We need an analytics dashboard so that authors can gauge the success of their articles"
5. Design direction: A general sense of how we want the product to look and feel
   • e.g., "The news application will have a simple, bold design meant to steer users toward the important campaign finance info for their state. For this project we especially want to avoid cluttered, unreadable, or overly complex design. The interface will include an easy to parse overview of the data (chart, etc.) and then narrow in on the ten individuals who have donated the most money. For each individual we will include a photo and key facts presented in a card-like style."
6. How we are defining and measuring success (analytics, special promotion plans, sharing tools, etc.)
7. Any areas where we need outside help or support from a member/client's team (i.e., things we can't do)
8. Schedule: List project kick-off date, important milestones for feedback, drop dead dates for introducing feedback or new features, and projected launch dates
9. How it will be maintained (project lifecycle) and any future plans and considerations
10. Big questions, concerns, or obstacles

Making the thing. Once all stakeholders have received and signed off on the project summary, we begin building. Some of this may have been covered in initial planning conversations, and many of these steps may happen in tandem (especially toward the end of the process), but in general:

1. We start by sketching out interface designs and general structure of features and apps. What does the user need to do first? Next? How do they move between those tasks? How will this work on all screen sizes?
2. From those sketches, we create wireframes for the project or feature. Depending on the project, stakeholders may need to review wireframes or initial prototypes
3. Again depending on the project, we may create a style tile or other general design inspiration board to give the client a sense of where we're heading and give them an opportunity to offer input (without getting bogged down in design polish too early in the process)
4. Design > code > review > refine > repeat. At this point in the process we are aiming to get a rough prototype up and refine that prototype through a series of code/review cycles. During this part of a project, design feedback is focused on functionality, structure, and UX needs.
5. Demonstration and review with stakeholders. At the end of each iteration, we will touch base with the stakeholders to demonstrate and review features to make sure we're on the right track. Are we meeting our goals? Is the product accomplishing everything it needs to?
6. Design polish. This is where we get the feature ready to launch — finalizing colors, CSS interactions, spacing, and other styles.
7. Final stakeholder check in and feedback deadline. (Feedback at this stage is limited to interface polish, not major functionality or feature additions — those can go in the next iteration.)
8. Browser testing, QA, beta testing. Listen to feedback and prioritize what needs to be fixed before launch.
9. Launch

Share the work. We will share our work, both by open sourcing the code and by writing about the projects we launch. Team members will take turn blogging, creating readme files and other documentation, and responding to any pull requests or bug reports. This also includes planning for how we will distribute and promote the projects that we publish.

Review and planning. After launch, we will review the project and how things went, and discuss next steps for the project. This conversation should include stakeholders, who can provide feedback on how we could do better, what they need for future projects, or planning for the next version of the product. We use what we learn to make the next project better and to refine our process continually.

Jargon, defined

Stakeholders: The people who are meaningfully involved in a project and have influence/decision-making power.

User: Anybody who is going to end up using the feature or product. These are often your readers, but don't forget about internal users (editors, reporters, business staff, etc.).

Iteration: This is a cycle of work, often two weeks (sometimes shorter or longer). It can also refer to a version of a feature or project, and implies that you will build on something over time. For example, in the first iteration of a project, you might only launch with a simple set of features. Then after publishing, you can add or develop new features based on the feedback you receive and how the product functions in the real world.