Edit
Digital Release Phases – EMBL Communications

EMBL Communications

Informing, inspiring, and engaging society with EMBL’s research, services and training

Mark Boulton

Category: Digital General

Digital Release Phases

Delivering digital products used to be about working in a ‘waterfall’ way: first gathering requirements, then writing lengthy technical specifications, drawing Gant charts, estimating delays and expense and so on. Maybe something would get released at some point. Maybe it would be good. But often not. In my experience, this really boils down to one problem: waterfall assumes you know what you don’t know.

The digital landscape shifts quickly. Users engage with content in different ways on different devices. Their expectations of technology changes monthly. To deliver really great digital experiences, therefore, the process needs to map to that speed. It needs to accommodate change – from technology to design. That’s why, in the Strategy & Communications team at EMBL, we’ve been working on documenting digital delivery phases.

These phases aim to address a few key issues:

  • They allow us to deliver more frequently. The goal is incremental improvement, not a Big Bang launch.
  • They provide a set of criteria on which a product or service can be evaluated. This is so the team gets the right type of feedback at the right time.
  • They allow us to course-correct as we learn. Major pivots in direction are painful, time-consuming and expensive and we want to avoid them.
  • We show The Thing. Prototypes are the primary way we gather requirements and document progress. We use them to anchor discussions. We show them to users and stakeholders. For digital product development, prototypes are *way* more efficient than meetings and documents discussing abstract things.
  • We work more openly, and at appropriate fidelity. Working this way focusses our attention. For example, initially, visual design of a product or service may not be the most important thing to focus on. This framework guides our attention onto the things that are important.

The Phases

Here are the phases. They are broken down into two lists: ‘To Consider’, and ‘You should do’. They are not prescriptive, but a guide. There are key differences between each stage in terms of prototypes developed within that phase.

DISCOVERY PHASE

TO CONSIDER:
1. Who are the users?
2. What are their needs?
3. What are the organisation’s needs?
4. Establish stakeholders
5. Establish advocates
6. Identify dependencies: people, technology
7. Technical: considerations, legacy systems

YOU SHOULD DO:

  1. User research
  2. Stakeholder engagement
  3. Assess legacy systems and need
  4. Make a backlog
  5. Assemble the team
  6. Define the minimal viable product (MVP) –
  7. Figure out some key performance indicators (KPI)

ALPHA

TO CONSIDER:

  1. This is a prototype service, so what level of fidelity should it be?
  2. Internal communications: to who, when and how?
  3. External communications: Is this valuable to the wider scientific or web community?

YOU SHOULD DO:

  1. User research
  2. Iterate if you have time
  3. Release and gather feedback
  4. Plan for Beta
  5. Articulate the purpose of the alpha

An Alpha is a NON-WORKING prototype. It DOESN’T HAVE to be designed or use production-ready code.

BETA

TO CONSIDER:

  1. A Beta release should be Private first – released to a small set of users and/or stakeholders to manage feedback before releasing to the Public
  2. Private beta communications. How to facilitate discussion and collaboration.
  3. Public beta communications. How to gather, parse, and act on feedback at scale.

YOU SHOULD DO:

  1. Test with users. Gather insight.
  2. Plan for launch
  3. Gather stakeholder feedback
  4. KPIs: measure and report
  5. Establish how to support the product to live and beyond (financial, resource planning, release schedule)
  6. Move to Live: Is it ready? Can we support it?

A Beta is a WORKING version. It adheres to design guidelines. Uses production code. Conducts real transactions.

LIVE

  1. Keep improving: user research, analytics, direct feedback.
  2. Training on usage: eg CMS
  3. Iteration and release cycle management

If you have any questions, let me know or post a comment. Over the coming months, we’ll be reviewing the phases and working on communicating this more broadly. But I’m hopeful that by clear labelling, the phases will become apparent as we build more prototypes and services.