In the last article, Designing a customer platform – UX, UI & Design Systems, we looked at the things to consider during the design phase of a bespoke customer platform project. The next step in the journey is the development phase, where you will bring your concept to life, test and fix and likely iterate until the product is ready for release to real users for acceptance testing and final launch.

What are the main stages of the development phase of a project?

When developing applications, we usually think in terms of the following activities:

  • Architecture planning
  • Agreeing to the final specification with the development team
  • Finalising the test plan and acceptance criteria
  • Creating a release schedule and setting expectations of what will be in each release
  • Developing the application
  • Testing & Bug fixes
  • Defining a launch plan
  • Launch day
  • Project review and future planning

 Let’s take a look at what’s involved in some of these stages. On the way, we’ll give advice, and tips and talk through some common problems. 

Selecting the proper framework and architecture

There are many programming languages, application frameworks, content management & CRM systems, and third-party services used in modern applications. Choosing the right combination for your current features and requirements with an eye to your future roadmap will help avoid the common pitfall of needing to re-platform too soon after launching and scaling.

Work with your development team/partner to ensure that they are aware of the following critical requirements of your solution:

  • Scalability
  • What device(s) will users be using to access the application/platform?
  • What are the security and compliance requirements for the application?
  • Do you have existing IT policies that define required software/database/hosting constraints?
  • Future features/capabilities that may impact your choice of architecture

Answering these questions will enable the development team/partner to recommend the most suitable setup for your requirements. 

Common combinations in modern application development include:

  • JAMStack and other Headless CMS approaches
  • REACTJS with GraphQL and containerised microservices running on AWS/Azure/Google Cloud Engine
  • .NET Framework with Azure services
  • Shopify with custom apps, Re-Charge and Klaviyo
  • REACT Native and Google Firebase
  • Ruby On Rails,Symfony/Laravel, and other open-source web application frameworks

Review user stories and acceptance criteria with developers 

Talk through each user story with the development team and review alongside the relevant UI designs.

 In this stage, you should:

  • Review and agree on the acceptance criteria for each user story defining any edge cases and providing the supporting copy for user messages.
  • Agree on effort/time estimates for delivering each user story.
  • Identify and workshop stories that are hard to estimate with confidence.
  • Prioritise your epics and user stories to help with release planning.

Set development goals and measure progress 

It is essential to set development goals with your team. Doing this helps manage expectations and enables you to monitor progress through the project delivery phase.

One way to do this is to work in 2-week sprints with a demo at the end of each sprint. Before starting each sprint, you will work with the development team to agree on the user stories, features, and fixes included in the upcoming sprint. Then, at the end of each 2-week sprint, you should run through a demo of the new features and ensure that they pass your acceptance criteria. 

Another method is to create a release schedule, much as you would create milestones. Each planned release should contain a list of the included user stories, features, and fixes. Working in this way is less agile but can be a good way of working with more significant epics and features.

Track how many effort points/hours the team achieves in each development sprint. Use this information to assess the accuracy of the original estimations; ask the development team to re-estimate the backlog items based on the learnings from the previous sprints where necessary.

User acceptance testing and giving good feedback

 In the second part of this series, we talked about the importance of creating your test plan and using it through the development phase of the project. As your development team pushes out new demos and releases, you should be using and updating your test plan to ensure that the application is fit for its purpose.

If you have the budget, we recommend using a dedicated testing resource to run through the test plan for each sprint demo/release using the different target devices defined in your requirements gathering. You must collect the results of this testing and your acceptance testing into a format that can be acted upon effectively by your development team.

There is a definite art to giving good feedback and reporting bugs and issues back to your development team. Here are some tips to help you get this right: 

  • Keep a log of the test name, the browser/device combination, the user account (if relevant), and the rough date and time of the error.
  • Describe the steps that you took to replicate the error/issue.
  • Take screenshots and name them with the test name. If relevant, annotate the screenshot to highlight the manifestation of the issue(s).
  • Use a ticketing system like Jira that allows you and the development team to manage communication and chart the progress of development work.

Issues, bugs, and change requests

An indisputable fact is that all software projects have bugs. Therefore, it’s essential that a) everyone on the project team understands this and b) that you have a mutual agreement on how you’re going to manage the process and cost of fixing them. 

We find a good way of thinking about issues/bugs is to classify them into one of three types:

  • Simple errors in the coding or UI leading to something not working as expected
  • Unforeseen side effects of a process or interaction
  • Changes to the original scope of a feature or user story due to missing or updated requirements

The first type is usually easy to agree on and fix within the original scope of the project.

The second type is a little greyer. As developers, we try to foresee the various edge cases when writing the code for an application. Still, some are much harder to predict: this is especially true the more bespoke a UI is or the more complex the underlying architecture of the application. These bugs and issues can add significant amounts of time to the project timeline and need to be discussed in detail with the development team to find the best solution. Usually, this would result in additional budget requirements – think of unexpectedly uncovering a mains water pipe while renovating a building, etc. 

The third type is a bit clearer, although there can still be grey areas in interpretation. Having detailed user stories with good acceptance criteria and ensuring that you spend a sufficient amount of time reviewing the UI design for approval can reduce the number of these types of issues. Still, they are relatively unavoidable in larger projects, and again, you should budget for this at the start of the project in the form of a contingency budget.

Launch Day and beyond

Preparing well for launch is essential. This stage includes:

  • ensuring you have a separate UAT and production environment
  • populating your application with the final launch content
  • ensuring all tracking, third party integrations, and data collection mechanisms are set up and working correctly
  • planning the onboarding of customers/users
  • developing a launch plan with all project stakeholders
  • agreeing a final date and time (not Friday afternoon!!) for launch
  • communicating the launch to customers/users

Once you have launched and have users onboard, it’s time to start monitoring the performance of your application against the KPI’s you defined in the discovery stage of the project. Gathering good qualitative and quantitative feedback on the system is the best practice. It enables you to make iterative changes with a “test and learn” approach and provides you with the data needed to make more significant feature changes and investment decisions.