This process outlines how client projects operate when the API is created independently of the client implementation.
Step 1. Research
Includes: Product managers
Starts: ~3-6 months ahead of a client project start date. Much of this will likely happen with the API project.
This time is set aside for the product manager to gather information and create documentation that enables design.
Input:
- Finalized Product requirement document (PRD) from the API project
- Completed API docs
- When an API doc is considered complete will need to be determined on a case by case basis depending on how new the Banno data models will need to be
Output:
- Product brief for client project (this is the first section of the PRD containing the problem statement and high level goals)
- PRD for client project (This may be combined with the API PRD depending on scope)
- Includes the data available from the API in a human readable format for design to know what they can include in the UI
- Includes error states from the API
- Open questions and incomplete requirements are expected, which will be answered through the design process and finalized by the start of engineering development
- All client teams should use the same PRD
- Project notes document
- Slack channel for the project
- All teams (PM, design, engineering) should utilize the same channel as the associated API project that came before. This ensures historical context is retained and ensures all parties know what channel to reference for a project.
Step 2. Ideation
Includes: Product managers, Designers
Starts: Dependent on the scope of the project. Could begin as the API project is wrapping up. An average medium sized project would allow ~2 weeks for designers to create a multitude of options to explore.
In this stage, design meets with the product manager to understand the problem we’re solving and the constraints around the project (API). Design spends time researching and ideating to create multiple concepts to bring to the next step in the process–where engineering managers and architects can offer feedback.
Input:
- PRD for client project
- Includes the data from the API in a human readable format for design to know what they can include in the UI
- Includes error states from the API if available
- Open questions and incomplete requirements are expected here, which will be finalized by the start of engineering development
- Slack channel for client project
Output:
- Multiple design concepts that solve the problem
- Concepts show what we can do with the provided API, as well as outlining if there is anything additional we would like to do for our client implementation
- Prototypes
- Questions about what’s possible
Step 3. Exploration
Includes: Product managers, Designers, Engineering managers (EMs), Engineering architects, Mobile Test manager
Starts: Dependent on the scope of the project–an average medium sized project would allow ~4 weeks for designers to create a multitude of options to explore with the larger team. The Product manager should schedule the first meeting with all the necessary teams represented. During that first meeting, the team can discuss what future meeting cadence is necessary.
In this stage, the cross functional team collaborates to explore proposed design ideas. Based on feedback, multiple design iterations take place which result in a final design direction vetted by the cross functional team.
Communication and collaboration take place during regularly scheduled meetings. Asynchronous channels are used between meetings to keep project momentum.
If Online and Mobile projects are happening independently, EMs from all client teams need to be involved at this stage.
This does not include the engineers who will be actively building the project. It is the EMs responsibility to communicate necessary information and decisions from this stage to others involved later in the process.
Input:
- Product brief for client project to sufficient detail that client engineers can grasp the full scope of the project. Open questions and unfinalized requirements are the expectation. These will be iterated on during this phase as well as Planning. The PRD should contain the mappings from API data models to UI elements when it is not obvious.
- PRD for client project
- Multiple prototypes that show what we’d like to explore building
- This is meant to facilitate conversation and collaboration around how much time things will take, and if there are other things to consider
- Documented big unknowns and questions about what’s possible
Output:
- EMs determine the level of effort required
- A single design direction and prototype agreed to by the whole team
- High level planning across the project with potential milestones
- Understanding of any engineering refactoring needs
- Answers to all big unknowns
- List of data, states, and users needed for testing created by Engineers and Product managers
- This is separate from the acceptance testing document. It should be easy for whomever is configuring the environments to understand what is needed without deciphering the User acceptance testing spreadsheet.
- The list should be communicated at least one week before the environment is needed. If we’re dependent on data from a third-party system other than core or NetTeller, then additional lead time may be needed.
- Delegated team to configure the environment. This could be a BA, the Mobile Test team, GoDough, or NetTeller depending on the project.
Step 4. Planning
Includes: Product managers, Designers, EMs, Engineers on the project, Mobile Test team, NTQA team, Operations
Starts: When the designer can provide a solid, single concept that the team has decided to move forward with.
This is the time for the engineers who will be building the project to evaluate the design direction and plan or fill the gaps in the documentation necessary to start coding.
The timeline is meant to be short and efficient, with consistent communication from all teams. Developers involved will be expected to focus on this project and not split their time between multiple other projects. This time is allocated in Jira for client engineers, and will be the start date for client teams. Mobile test team members will not be completely dedicated to the project as they are assigned to more than one project at a time.
When this stage is over, there is a solid understanding of what this project is from all teams–design is mostly complete, and it is ready for engineers to begin coding. Product managers can finalize the acceptance testing document and prep for the operations handoff and release.
Input:
- PRD for client project in sufficient detail that client engineers can plan and estimate the project. Open questions and unfinalized requirements should be minimal and will be refined and completed during this phase.
- Single design concept with a prototype that shows the structure of what we’re building
- Completed API documentation
- Finalized error states
- BA Flow diagram
- Dedicated Engineers for the project: Two for Android and iOS, One for Online
- List of data, states, and users needed for testing
Output:
- Finalized PRD with all open questions answered
- Defines what data models clients need to know to get the data points shown in the UI design (not what the API endpoint is–clients should determine which endpoints makes sense for them)
- Documents questions and answers (including any data modeling decisions) from client team EMs during engineering exploration so the next client team has the answer and doesn’t need to ask again
- All error states from the API
- Design spec
- Abstract layouts
- Solidified engineering plan
- Client flow diagram–all client teams collaborate on the development of this document
- Fill in gaps in API documentation if necessary
- If a gap is identified, the PM will connect the correct client and API engineers to resolve the problem. Communication should happen in the client Slack channel. If the services engineer needs additional help answering the question, they will involve the BA
- Once the gap has been filled, or the question answered, it may result in the PRD being updated, or it may involve an update to the API docs
- Completed operations readiness assessment and meeting
- Established testing environments with required data, states, and users
Step 5. Development
Includes: Engineers coding the project, Mobile Test teams, and NTQA team–Product managers and Designers are involved as needed
Starts: When all design artifacts and planning documentation for the project have been provided to the client engineers.
This is when client engineers are actively developing the design with code. There will be small discoveries that need to be made to adjust designs as engineers get deep into their work.
Input:
- Finalized PRD with data modeling information/decisions
- API docs
- Design spec
- Abstract layouts
- Engineering plan
- Client flow diagram
Output:
- Updated design spec and Abstract layouts if any changes were made
- Functionally complete code that might need some polish
- Videos, screenshots, APKs, or UAT environments to share with product and design
- In-progress acceptance testing document
- Completed operations mid-point check in
Step 6. User acceptance testing
Step 6a. Integration Testing Includes: Engineers on the project, Mobile Test team
Starts: Mobile As Story tickets within the project Epic are moved to “Ready for Test” Online As PRs are submitted for peer review
The Mobile Test Team engages early in the project and begins testing as mobile engineers mark functionality as ready to be tested by the Mobile Test Team. This step will often overlap Step 5. When all Stories are marked complete, the Mobile Test Team will conduct a final round of Integration Testing to ensure the implementation of the mobile apps of the API works properly and the feature meets the requirements.
The Online Team performs integration testing as part of the PR review process with each Online Engineer reviewing PRs for API calls and errors.
Input:
- Finalized acceptance testing document
- Established testing environments with required data, states, and users
Output:
- Validation that feature is ready for User Acceptance Testing
Step 6b. User Acceptance Test Demos Includes: Product managers, NTQA team, Designers, Engineers on the project, Mobile Test team
Starts: Once there is a feature complete client solution.
At least one acceptance testing meeting occurs where the entire project team gathers. Each team takes a turn sharing a screen and working through the acceptance testing document. Engineers provide screenshots, videos, or UAT environments for design to review outside of the meeting to ensure the designs have been implemented accurately.
Input:
- Finalized acceptance testing document
- Validation that code passes the acceptance document by Mobile Test team
- In-progress operations guide
Output:
- All release blocking design issues in Jira have been closed
- Completed (all green) acceptance testing document
- Published operations guide and knowledge base content
- Identified design and tech debt for future implementation
- Release ready code
- Operations handoff
Step 7. Internal documentation
Includes: Product managers, Engineers, Mobile Test teams
Starts: Shortly after UAT, or at the same time as the feature is being released
This is when the Product manager and Engineering teams document the result of what they built and why they built it that way. Documentation should not be release blocking, but time for it should be prioritized and at a time when all the right people are still engaged with the feature.
Input:
- Finalized PRD
- Provides much of the ‘how it works’ information
- Client’s finalized flow diagram
- Rounds out what’s missing from the PRD
Output:
- Finalized internal feature documentation so our teams can reference what was built and why
Additional information
Asset organization
Jira product initiatives will be the central location to house links to all project documentation.
Client engineering definitions
UI complete: All design requirements have been met and can be reviewed and approved. Data/Services/APIs may still be mocked out and have minimal/no influence on the UI.
Functionally complete: All functional requirements have been met and API endpoints have been fully integrated–the UI may still be stubbed out or need additional polish
Feature complete: All design and functional requirements have been met (UI + Functionally Complete)–Client solutions have been fully tested end-to-end
Release candidate: Client solutions have passed UAT–all outstanding issues have been addressed or assigned to future milestones/maintenance efforts. This represents a release candidate for the feature.
Product requirements document (PRD) definition
The PRD is a document made up of two primary sections: The product brief and product requirements. The former is the very first piece of project documentation that predates the project being roadmapped. It describes in detail the problem our customers or their users face and includes high level goals which, if met, solve that problem. Each goal is backed up by job stories, describing specific examples of users encountering the problem. The brief section is used to establish an initial level of effort and estimate for the roadmap. The second section, product requirements, comes later in the project but before design, analysis, and engineering actually start any work. This is a more detailed set of requirements tightly coupled with the goals and job stories from the brief. For client projects, the requirements will contain links to API documentation and some of the expected API data outlined in a human readable format for designers.
The PRD as a whole is a living, breathing document and is ultimately the product of collaboration with the project team—anyone should feel comfortable commenting and asking questions in the PRD. As open questions are asked and answered, the PRD gets closer to becoming a final set of requirements for a project.
Design specification definition
The design spec is a multi-page document that explains the user experience of a feature based on the information in the PRD. It outlines the actions that can be taken in the UI and how the design should respond. It is not meant to include documentation about styling. This information should be inferred by directly inspecting the design in a tool like Abstract or Figma. The design spec should cross link project documents, be used as a source of truth during the user acceptance testing phase of a project, and be considered one of the supporting pieces of project documentation alongside the PRD.
Recommendations for when API and client projects run in parallel
In some cases, timelines constrain our teams to running both API and client projects in parallel. In such cases, several facets of the split process aren’t effective and should be consolidated.
- As referenced in the process, make sure to stick to one Slack channel. When separate channels exist, inevitably almost everyone joins both, leading to confusion.
- Maintain one recurring meeting for both API and client projects. Client teams want as much information as they can get as early as they can get it, and services teams want their feedback. The key is that client teams and design won’t drive the APIs, but their feedback is welcome.
- When consolidating meetings with API and client projects, make sure to use an agenda and be cognizant of everyone’s time, as certain discussions do not need to involve the whole team.
Milestone approach
Ideally, projects will be scoped to not have milestones. Instead, they will be organized into smaller, shippable projects. If we do have a project where milestones are needed, the project team should define which pieces of this project process need to be repeated.