Streamline frontend/backend cooperation towards minimum viable product (frontend prototyping)

Assumptions

• we face a deliverable that frontend and backend team work on together
• it is not a small feature / bug fix
• frontend and backend specification may not be complete
• frontend and backend work is generally independent and may be done in arbitrary order

Current process

current-workflow.graphml

Remarks

• Feature proposal describes the initial deliverable description; coming from product manager for simplicity, may be started by a customer/user
• UX specification includes design as well as desired behavior/workflow
• Backend refactor contains code style or performance changes but does not add further functionality

Problems

Late backend specification

late-backend.graphml

Some requirements to the backend implementation may only be known after the frontend implementation has started. This may cause the backend implementation to be delayed and the frontend implementation to be blocked.

Late UX specification

late-ux.graphml

Some adjustments to the design or the behavior/workflow may only be possible after at least a basic frontend implementation is done. This may cause duplicate work to be done and the frontend implementation to be delayed.

Late user feedback

late-feedback.graphml

A product manager/customer/user can only try out the deliverable after at least a basic frontend implementation is done. This implies that reducing the feature scope or making major changes to the behavior/workflow may happen after the backend implementation is already finished.

Suggested change

suggested-workflow.graphml

Remarks

• Feature proposal describes the initial deliverable description; coming from product manager for simplicity, may be started by a customer/user
• UX specification includes design as well as desired behavior/workflow
• Prototyping is a frontend implementation that is complete regarding design and behavior/workflow; it does not contain
  • backend calls (unless it's easier to include them)
  • correct text copies (unless they are already provided)
  • automated tests (I think it is realistic to say that we are already not embracing test driven development)
• Backend specification results in a detailed description of new or changed endpoints and entities that frontend needs from backend
• Backend refactor contains code style or performance changes but does not add further functionality

Goals

• after UX specification, no changes are made to design or behavior/workflow in UX review (missing specification may be added though)
• after Backend specification, no changes are made to the backend endpoints
• prefer starting a new iteration over making changes to the specification during implementation

Improvements

Earlier UX specification

early-ux.graphml

During the prototyping phase, design and behavior/workflow can be iterated on such that those are specified before the deliverable is scheduled. This gives UX team and product managers (or even customers and users) the chance to try out different solutions with reduced costs. It also makes the direction for the frontend implementation clear from the beginning.

Earlier backend specification

early-backend.graphml

After the prototyping phase, requirements for the backend changes should be specified. This implies major road blocks can be found before the backend implementation is started (or even scheduled). It also gives the backend team a better chance for structure and performance considerations in advance.

Earlier user feedback

early-feedback.graphml

Feedback by product managers/customers/users can already start during the prototyping phase which is roughly one release cycle more than with the current process.

Exceptions

Small

All deliverables that require no UX specification in advance can be considered "small". They probably don't benefit from this suggested workflow. This includes (but is not limited to) frontend deliverables without backend changes. An example of a small deliverable could be to fix commenting on an issue as it is mainly restoring functionality that existed before already.

Clear specification

Deliverables where the specification is clear from the beginning and where the chances are very low that they change during implementation will likely not benefit from this suggestion either. An example would be adding an attribute to an existing API endpoint and displaying it as-is on the frontend.

Additional thoughts

• When using Vue.js + Vuex, the UI components from prototyping can basically be used as they are for the implementation. Only the store actions need to be adjusted to make backend calls rather than returning mock data.
• The suggested workflow requires to plan deliverables more than a release in advance. In the end, this probably doesn't make much difference because some deliverables are delayed and get pushed to the next release already.