From press releases about our latest discoveries and recaps of alumni or sponsor events to conference announcements or service updates – EMBL has many stories to tell to a variety of local and global, general interest and expert audiences. The digital channels we’re currently using for this are just as diverse:
On 26 July, in a preparatory meeting including members of the Strategy & Communications as well as the EMBL Heidelberg and EMBL-EBI web teams, we have decided to make news delivery the topic of our first ‘sprint’ to kick off EMBL.org, the project to create a new website for EMBL. A sprint is a short time period (usually 2-4 weeks) or iteration, during which a usable version (or ‘increment’) of a product is created.
For a start, we feel that – on top of suffering from various technical issues – news.embl.de doesn’t serve the needs of the whole organisation very well. Three years after its launch, we want to take stock and re-assess its fitness for purpose.
At the same time, our designers were looking for a suitable test case to apply some of the new principles they’ve developed during the first sprint of the corporate design project; with the news site being separate from and running on a different system than the main website, it serves as an ideal candidate.
Thirdly, we’re looking forward to bringing the different teams – design, development and communications – together in a pilot project to find out how we can collaborate between departments and across sites: which methods work best, which tools to use, how to make the most of our limited resources?
We’re planning to run our first EMBL.org sprint, web1, for three weeks, starting in mid-September. In the run-up to this, members of the project team will contact stakeholders from all EMBL sites for their input, which will form the basis of a sprint planning meeting at the beginning of September. Whether we’ll build on or improve the current news site or start building a new one from scratch will depend on the feedback we’ll get, coupled with an assessment of what we have now.
To get an idea of the requirements various audiences and internal users (such as content providers or those editing content on the website) may have, we’re working with user stories. In contrast to more detailed features or requirements, user stories are very high-level descriptions of what a user tries to achieve with a product, and to what end (and not so much how). They follow the formula
As a [type of user], I need to [goal] in order to [reason/value].
‘As a service owner in Hinxton I need to notify people planning to access the service over the weekend that there is scheduled maintenance so that they can arrange to use it at another time.’
They form the basis for the discussion in the project team about which requirements to prioritise and tackle during the sprint, and how to implement them.
We’d love to hear your user stories! Please submit them via our user story form or get in touch if you’d like to get involved or provide feedback! User stories submitted by 1 September will be taken into account for our first sprint.