Preparing for Beta: How to Iterate Post-Alpha Launch

Iterating and Creating Feedback Loops After Launch

After finishing the prototype, build, and alpha release phases - you are now ready for launch! Whether you’ve launched a report, project, campaign, new software, or something else, this is a moment of celebration. Once something new is released to the world, people are often eager to use it and provide feedback. The existing community, new users, or other audience members can share their user experiences, which will help you refine your project for beta release. This also gives you time to work with your development team to spot code, usability, and front-end errors so you can make fixes to improve the end-user experience.

It’s normal for changes or updates to happen frequently after a launch, but since the product or service is already live, it’s important to be transparent with the community and new users so they can be prepared for new features or bug fixes. Since iterating and feedback are going to be continuous, this chapter covers steps for what to do after launching and how to best communicate with your audience about updates.

In an HRCD process, you can work towards more equitable designs by incorporating on-going user feedback into your iterations and updates. Remember, the HRCD product cycle is an evolutionary process. Nothing is static and, in order to make a space truly safe or valuable to a community, you will need to continuously work with them to ensure those qualities.

Users are central actors in this ebb and flow process. They are now stakeholders and can be affected by any changes you make, so it is important to do so with care. Supporting your user's experience includes being transparent about what changes and updates are made and why, what will change for that user’s experience, and where they can share feedback and receive support for these changes.

All things need to be updated! We can’t stress this enough, so we’re going to review why it’s necessary to have ongoing updates. Technology is not cast in stone; it evolves and needs to be maintained and fixed. Maintenance is a part of any product upkeep. When coding libraries and protocols your code relies on are updated, you will be required to update the code within your project.

Beyond maintenance updates, the design and development team are responsible for learning from repeat usage and the community to understand how the tool can continue (or better!) serve their needs. This is especially true as our global, geo, or political climate changes. Perhaps a feature that was designed to keep a certain community safe is no longer doing so and instead allows them to be targeted within the tool. Maybe what seemed intuitive actually isn’t. The changing community needs must be reflected in your project and embedded in the updating process.

Once an issue or change has been identified for an update, it’s valuable to go back through the HRCD process to repeat the research, iterate, and ideate phase before publishing changes. After having completed the process and determining that the update is ready, it’s time to inform the community about the changes that are about to take place. It’s imperative to create a consistent space to place the update and explain the changes you’ve made, why you made these changes, and how they changed the technology. Being able to contextualize the update is a vital component of the HRCD process. It creates a channel of communication that allows community members the ability to provide feedback outside of user testing and product ideation to share how the changes will impact them. To practice meaningful and HRCD informed transparency, users and community members must be treated as active participants in the post-launch process. Therefore, you have to create a place where community members can offer feedback and engage with the changes you’ve made. It is helpful to have a dedicated space on your website or platform that is easy to find and not buried among the site's contents. The more clicks it takes to reach the information or hidden this section, the harder it is for your audience and community to find out more about your updates and feel like they trust the people behind the platform or service they use.

Often when engaging users and community members, companies draft blog posts or public announcements via social media. Others might explicitly describe the update via GitHub or mobile app store updates. However, app store and code updates via GitHub are not accessible to everyone, and blog posts or social media updates can be easily missed among the many things posted online. To appropriately share updates with your community, it is recommended to use a variety of mediums. This means to share across blog posts, social media, email, notification on the platform, coding platforms, app store updates, messaging services or wherever else you have a presence. The key is to create an open channel of communication between you and the community. This two-way dialogue enables the community to comment and add feedback to the changes you’ve made, while allowing you to respond directly to their needs and suggestions.

Also, important to note are the communications channels that were set up with the community during the research and development process. This could look like a Signal Group, WhatsApp group, Slack channel, or Listserv. These established channels are direct to your early audience and can sometimes feel more personal to a highly engaged stakeholder list.