Phase 4: Launching
  • Intermediate Level
  • Individual quiz activity and group discussion
  • Pen/Paper, Post-its, Computer Text File
Phase 4: Launching
Chapter 10

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.

Updates Happen (And They Are Necessary)

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.

How to Update Your Community About Your Updates

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.

Exercise 1: Prepare a Beta Release Through Iterative Research

Once you have a final product, it’s time to prepare a thorough release strategy and document the process. It is very important to nurture a culture of feedback once the product or service is ready to be released. Investing in experts or advisors to help review before the release can help you create a feedback gathering plan and agenda. Your research continues in this phase as you are coming back to the conversations you had with your early user testers to share updates and gather any additional feedback. Use the checklist below to ensure you are ready for release and understand any gaps that still exist.

Distribution Strategy

  • I have a clear messaging for my user of why and how this tool can help them, as well as how to get it.
  • I am working with someone who has relationships and trust in the communities I am reaching out to.
  • For gathering feedback, I am providing people with safe channels to contact me (e.g., end-to-end encrypted emails).

Training and Documentation

  • I have created and tested a user manual or guide. I keep updating it based on the testing feedback.
  • It is easy for people to see the updates for my tool / technology / platform. (Consider if you have a public webpage or portal and if you regularly update them and track the updates.)

Evaluation and revisions

  • I revisited my research methods and analysis.
  • My work met my original research objectives.
  • If I have learned anything new in the test, I have written it down in my documentation.
  • I have a contingency plan for unexpected situations (e.g., Connectivity issues, a trusted alternative network, Code of Conduct, a mechanism for reporting problems, etc.).


Comms and Info Gathering:

  • It is always a good practice to allow people to reach you securely and anonymously. Consult newsroom whistleblowing platforms for tips and recommendations.

Evaluation and revisions:

  • It is particularly important to set a Code of Conduct and problem tracking mechanism for your tool / tech / platform if you aim to nurture a community through your rights-protecting product or service.