MediaLAB Amsterdam is now the Digital Society School! You are viewing an archive of MediaLAB projects. Content on this website may be outdated, and is without guarantee.

Scream Team

Just another MediaLAB Amsterdam Sites site




Sprint 6: Wrapping up!

It has been a while since we finished sprint 5. Today we will already present our final outcomes at the final presentations! In this post we will talk a bit about what we have done in the past weeks in preparation for today.


We have been mainly working on finalizing the product. This means creating the design persona, writing the research paper and building the actual website. However, for the final presentations we had to focus on a research poster and a final video that represents our work. We will share a bit about this process here.

The final video

In the first part of the video we try to explain the problems of the writers and the readers. We used two different background colors to show the difference between the writers and the readers. Through animation we show the problems that the creatives deal with.

Screen Shot 2017-01-18 at 10.15.58 AM Screen Shot 2017-01-18 at 10.15.32 AM

Secondly, we introduce the SCREAM! tool and explain some of the functions.

Screen Shot 2017-01-18 at 10.16.16 AM

In the third part, we show how our tool solves the problems for the writers and the readers, and how it subsequently can prevent design waste through a sharing community.

Screen Shot 2017-01-18 at 10.16.45 AM

The research poster

The research poster shows the process through the problem statement, the methods, the results and the conclusion. We tried to make it look a bit like our SCREAM! tool in order to create a consistent visual language. The posters therefore starts with the aim of the project. Secondly, we we explain the definition of design waste and how it is related to SCREAM! and the Design Method Toolkit. The third part introduces the design challenge and our target users. The methods and results follow and these are linked to the SCREAM! tool (see image below). Screen Shot 2017-01-18 at 10.24.14 AMWe end of course with the conclusion, which is:

“Not sharing, finding nor understanding information complicates the reuse of knowledge in Multidisciplinary Design Teams. This phenomenon is defined in this research as design waste. Creating incentive for both the readers and the writers will create a sharing community. This should subsequently prevent design waste in the Multidisciplinary Design Teams.”

The final presentations

This afternoon we will present both the video and the research poster at the ACIN LabFest. We are looking forward to show our product to others and share our ideas, thoughts and insights!


Sprint 5: Finding the ‘aha’ moment

Previous steps: We wanted to change the mindset from documenting to ‘communicating your process’, because based on this insight we figured out the incentive for the writer to use the SCREAM! file.


The aim for this sprint is to implement a skeleton of the SCREAM! tool on the Design Method Toolkit website, based on the refined wireframes.

The minimal viable product for this sprint is a skeleton of the SCREAM! tool (where users can log, update projects and create/edit sprints) and the refined wireframes.

The conclusion of this sprint is that user experience is very important for the tool and it needs to be as intuitive and simple as possible.

Key insights


We defined the ‘aha’ moment for the reader and the writer



We defined for both the reader and the writer the moment they experience the added value of the tool (‘aha’ moment).

  • For the reader it happens when he/she is able to find valuable information.
  • For the writer it happens when he/she is able to extract (new) insights by writing.  

We tried to minimize the steps towards achieving these ‘aha’ moments.

  • For the reader this means that he/she should be able to search/filter and browse the projects to find the relevant projects. Besides that there is the sprint summary that gives the reader a quick preview of what happened in this sprint.
  • For the writer we decided that there should be 4 phases instead of the 3 we created last sprint . Each phase should focus on one important action to make it less complex. Besides that, the phases should be part of the workflow of the writer

The four phases

Which events led to this insight?

We researched user onboarding experiences and we refined our wireframes based on the findings.



The writer needs guidance to understand the process



  • To feel how long/easy the process is
  • To be able to navigate through the tool
  • To understand why the tool asks for certain information

Which events led to this insight?

We researched onboarding and text framing and we refined our wireframes based on the findings. Besides that we did a user test last sprint for the writer’s SCREAM! file. 



Results and references are in some cases needed for the reader to understand the process



For methods such as the literature review, it could be helpful to have a full summary with references. Therefore we have added a page for photo’s, files and links. The writer should always add a title and a description to the upload to make sure the reader is able to understand.

Which events led to this insight?

We have tested a reader’s SCREAM! file with another MediaLAB team that is working on a solution for the baggage reclaim area in Schiphol.



Next steps: Sprint 5 is over! This means only one more sprint to go. Crazy how fast things go. The last sprint will be all about designing the interface, building the skeleton and wrapping up the project!

Sprint 4: What is ‘communicating your process’?

This blogpost has the same structure as our final product: also known as the SCREAM file. The first part, consisting of our aim, our minimal viable product and our conclusion, is the summary of the sprint. The second part consists of the main insights, the reasoning of it becoming a main insight and which events led to the main insight. 


Our aim is to create a prototype for a sprint based SCREAM file and test an efficient way to fill it in

Our minimal viable product is a readable sprint based  SCREAM file and a suggestion to how to fill it in

We got the conclusion that we wanted to change the mindset from documenting to ‘communicating your process’, because based on this insight we figured out the incentive for the writer to use the SCREAM file


Our main insights were:

#1 We decided to change the SCREAM file from method based to sprint based


  • It is easier to see/feel the process for both the reader and the writer
  • Other events in the process (meetings, discussions, workshops) can be as important as methods
  • It is more about gaining insights for the writer
  • It is easier for the reader to navigate

Which events led to this insight? We met with our partners for our partner review of sprint 3 and we did a reversed brainstorming session.


Reversed brainstorming – We needed a lot of post it’s and tea and cookies for this session

#2 We decided to the concept of milestones to events (which includes methods, but also other important moments in the process)

Why? The concept of milestones was found to be very confusing by the coach. While concept sketching we decided to go with the term events.

Which events led to this insight? We had a translate session with one of the coaches, we did a lot of concept sketching for the prototypes and we had a discussion about the writers SCREAM file.

#3 We decided to change the structure of the writers SCREAM file from a linear form to phases that includes a workspace

Why?  When ‘communicating your process’ the user is going through 3 phases. The first one is starting up. This happens during or after sprint planning. The user has to provide the information through a form filling structure. The second phase is the workspace. The user uses this phase to add events and insights. The third phase is connecting the dots. This happens at the end of the sprint before you want to publish. The user combines the insights from different events into main insights.

Which events led to this insight? We had a discussion about the writers SCREAM file and we created a wireframe for the writers SCREAM file.

#4 We decided that we wanted to change the mindset from documenting to ‘communicating your process’

Why? The phrase ‘communicating your process’ has a more positive connotation than the term documenting.

Which events led to this insight? We had to define our vision for this project by making decisions and defining concepts and terms.

#5 We decided that we should reverse the structure of the landing page of the readers SCREAM file from method centered to main insights centered

Why? Main insights are most important to the reader when seeking for valuable information according to our user research.

Which events led to this insight? We did a card sorting game, a reversed brainstorming and a lot of concept sketching.


Card sorting game – participants prioritized the elements through a card sorting game

Participating in the CryptoDesign Awards

On Friday the 25th of November, Anna Bleakly and Abdelrahman Hassan of Medialab Amsterdam participated as finalists in the second edition of the Crypto-design Challenge, which was held at the Paradiso. The competition was posed to help reshape the dominant image of the deep web through design thinking and innovative solutions. 15 out of a total of 36 submissions were selected by a jury to participate in the final event.

MediaLab’s contribution:

Anna and Abdelrahman’s submission was titled ‘The Ustopic Web’ and relied on showing two extreme interpretations of the deep web, a utopic one and a dystopic one. The audience then followed the journey of a fictional Thai activist as she navigates both webverses. The audience is able to slide the screen and alternate between the two webverses, finding a Ustopic Balance (Atwood, 2011).

More information on the submission can be found at

The event:

-The Crypto Design Awards event included talks from prolific speakers such as Ingrid Burrington, Tijmen Schep, Constant Dullaart  and Hendrick-Jan Grievink. The talks posed important questions about the nature of the deep web, privacy concerns and other social implications of poor design. Of the many critical themes discussed were:

-The marketing and accessibility of cryptography.

-The relevance of natural language metaphors

-The internet as a semi-public, semi-private space, much like the balcony.

-The physicality and infrastructure of the web.

-Protocol design and web art.


More about the Design challenge can be found at

Cryptodesign Challenge award opening note.

Cryptodesign Challenge award opening note.

Anna and Abdelrahman

Anna and Abdelrahman

The atmosphere at the Paradiso

The atmosphere at the Paradiso



Sprint three: What does the reader want?

We have finished our third sprint! Which means that we are halfway into the project. In this sprint we wanted to find out how to create a SCREAM FILE that is both useful for the documenter and understandable for the reader. We started the sprint by defining the elements that should be in this SCREAM FILE. However, when we started concept sketching we noticed that looking both at the documenter and the reader at the same time was very complex.


That is why we decided to focus on the reader in sprint three. If we understand what information the reader is looking for then we can think of ways to make the documenter provide this information.


In this sprint we wanted to create a “perfect” SCREAM FILE for the reader. This SCREAM FILE is based on the structure of the methods from the Design Method Toolkit.  To find out how this “perfect”  SCREAM FILE looks like we created four interface prototypes for the reader and tested them with the other MediaLAB teams. Based on these insights we created a “final” SCREAM FILE that we showed to our product owners.


To find out what the readers need in the SCREAM FILE we defined a list of elements based on the research from the past sprint. These elements were implemented into the four prototypes, each with a different look and feel.


On forehand we created a list of questions to find out how people felt about the prototypes. Based on the feedback that we got and The Elements of User Experience diagram by Jesse James Garrett we created a “final” prototype.


  • We are going to switch the SCREAM FILE from being method-based to being sprint-based
  • We need to create incentive for the documenter to fill in the SCREAM FILE
  • The current prototype is too complex for the reader
  • We have to create a coherent vision for this project


In the fourth sprint we are going:

  • Form a coherent vision for this project;
  • Make and test a prototype for data input by the documenter;
  • Make a prototype for a sprint-based SCREAM FILE;
  • Familiarize ourselves with the website where we will build our tool.

A lot to do! We will update you by the end of this sprint.

Sprint two: What is documentation?

Time flies! In the last sprint we changed our goal for this project. Our focus has shifted from the chatbot to documentation. We want to add a stand-alone component to the existing SCREAM platform to digitize, organize and prioritize the way people document their (non-)digital artifacts.


In sprint two we wanted to understand the setbacks and pleasures of the documentation process. The data that we got out of this, would be translated into personas and an infographic. We used two methods to get the data:

  • Method 1: a conversation tool that would help us find out how other MediaLAB teams think they document and how they feel about documenting;
  • Method 2: analyzing the digital folders from other MediaLAB teams to find out how people actually do document.


Method 1

Our conversation tool consisted of three elements:

  • Categories;
  • Cards;
  • Fill-in story.

We came up with 6 categories for the conversation tool to get people to think about their documentation process:

  • Platforms;
  • Events (related to the Scream method);
  • Attitudes;
  • Sharing (with);
  • Problems;
  • Kind of documents.

Besides that we created cards with examples that relate to the categories. For example: Google Drive, Slack and “my notebook”  were cards that belonged to the ‘Platforms’ category. By giving them categories and cards we wanted to lower the barrier for them to think and talk about their documentation process. To make the data even more concrete, we created 5 fill-in stories for them. They could use the cards from the different categories to fill in the gaps.

Conversation tool

Method 2

For the second method we asked the other MediaLAB teams to add us to their digital folders such as Google Drive and Dropbox. We tried to map the ways in which they structure their files. Besides that we looked at who uploaded what kinds of documents.


  • People have personal preferences when it comes to documenting;
  • Customization of the platform is important, but an “easy to use platform” has more priority;
  • People already document consistently, but not for the purpose of sharing (with the team and/or the world). This makes the documentation only understandable for themselves;
  • It is hard to classify behavior, especially with teams that are multidisciplinary and international


While researching we discovered that people have different opinions on the definition of documentation. We tried to create a diagram to map the terms that are related to documenting. We divided the files that you collect during your process into internal and external ones. We decided that the essence of documentation is within an extra layer of information. This information provides context for the reader of the documentation. This extra layer will be the SCREAM FILE, which will be the prototype that we will try to make and test next sprint. During the coming sprints we will refine our definition of the SCREAM FILE and its relation to the Scream method.



As you can see, we tried to do a lot of research on “how do people collect and create documentation?” in sprint two. In sprint three the focus will shift towards “how do people look for and read documentation?”. Besides that, we will start on making and testing a specific part of our documentation tool.



Sprint one: What is a chatbot?

Last week we finished our first sprint! It has been an exciting and interesting three weeks. In this post, we will update you with all the things that have happened since the ROEF festival. Besides that, we will explain what we are planning to do in the second sprint.

In the past three weeks we got insights through different events. After the ROEF festival, we started to prepare for the Global Goals Jam. The Scream application was tested for the first time at this event.We thought that the Global Goals Jam would be the perfect moment for us to get insights about how people react to a chatbot. That is why we prepared a chatbot simulation. We added our chatbot simulation to the Slack-channel of two Global Goals teams.

More information about the Global Goals Jam can be found here.


Insights Global Goals Jam:

At the Global Goals Jam we found out that there were some difficulties concerning the use of the Scream application and Slack.

  • Technical difficulties
  • Usability difficulties
  • Time & space difficulties

These difficulties made it hard for the participants to actually use Scream and Slack. Therefore our chatbot simulation was not used by the participants. 


This insight changed our initial planning. We now had to reschedule the ending of our first sprint. That is when we tried to really figure out “what is Scream?”.

On the 27th of September we had a Visual Thinking workshop. This method helped us to define our problem and gain a better understanding of Scream. We used this visualization to explain our vision to our product owner at the partner review on the 29th of September.



Insights Partner Review:

We explained to our product owner that we thought that it would be hard to add a chatbot to an platform that is not “mature” yet. He understood our perspective and we started to discuss different directions for our project. We decided to focus on DOCUMENTATION, because this is the crucial step to prevent design waste according to the Scream method. We realized that choosing this challenge is going to be complex, because it has a lot of facets. Even so, we find this challenge very interesting and we think overcoming this challenge would contribute to the Scream method.


In the second sprint we investigate more thoroughly who the actual user of Scream is. Besides that, how do these users document their process (if, how, why, when)? Sharing is an important part of preventing design waste as well. Therefor we need to find out how and if we can motivate teams to share their process with the world.

Our next post will hopefully provide you with more insights about these topics!


ROEF festival: Presenting our visualization on the roof

On Friday the 9th we were invited by Maarten, one of the organizers of the ROEF festival, to present our visualization on the roof of the Benno Premsela building. ROEF festival is a festival that allows people to get access to several rooftops on the “Knowledge Mile”. You can find information about the festival and the “Knowledge Mile” here and here. The rooftop of the Benno Premsela building focused on media, technology and sustainability.



We changed the categories of our visualization a bit after we had our first partner visit on Wednesday the 7th. The category “Compliments” was changed to ” Motivators”, because motivations can be more than just a compliment. Besides that, we replaced “Prioritizing” with “Networking, because our partners were interested in this task as a feature for the chatbot.



A lot of people visited and were willing to participate, which was exciting for us. We told each participant that they were able to replace a human with a bot for each category. After 16 participants we took a picture of the results to keep track of the data. We were able to complete 4 rounds of participants in total.forever




We found out that the visualization looked different after each round. However, there were some similarities;

  • “Follow-up”, “Statistics” and “Guidance” were mostly covered by bots;
  • Participants seemed to agree that “Follow-up” is a task that a bot is able to do better than a human. There was not much discussion about this task;
  • Participants seemed to have certain assumptions about the function of a bot in a working sphere. When we started to ask them more in-depth questions, and gave them examples of scenarios, they saw it from a different perspective;
  • “Motivators”, “Networking” and “Suggestions” were often seen as tasks that need soft skills.

The ROEF festival was a fun experience for us! People realized that they had strong opinions about bots when participating in a simple visualization. These insights will be implemented in our first sprint. 


Makerssprint: “To Bot or not to Bot?”

This week we started our MediaLAB experience with a Makerssprint at the MakersLAB. The goal of this Makersprint was learning that creating a tangible product can be helpful to gain insights into a abstract problem.

We hoped to visualize two key problems:

  • How does a representation of a bot trigger different emotional responses?
  • Which tasks should be taken over by bots and which should be left to humans?

IMG_2592 copy

SCREAM! team brainstorming ideas

The visualization:

To visualize the problem, we started collecting unfiltered amounts of data about bot-human interaction. Then an ecology was formed, mapping the key relations and blackholes between our ideas. The ecology can be seen below:

IMG_2545 copy

The ecology revealed to us that there was a gap in our understanding of the correlation between humans and bots. Out of the many ideas we brainstormed to better diagnose the problem, two stood out:

  • An interactive mapping of the emotional response towards certain representations of bots;
  • An real-time interactive infographic tracking people’s sentiments towards the division of jobs between bots and humans.



Can I Help You?

Bot figures were created through laser-cut MDF. Representations varied from very abstract to very human-like.  The board, also made out of MDF, functioned as a matrix for mapping different responses. Users place each figure on the matrix to where they think it fit.

Human / Bots

Paper was used to fold pyramid-like structures that represented humans and bots. Humans were yellow colored, while bots were grey colored. Users were presented with a set of six different team-work related tasks. The human pyramids were laid out on the floor in a hexagonal formation, in allusion to the scream logo. Vinyl-cut letters were used as labels. Whenever a task is deemed more efficiently done by bots, a human pyramid is replaced by a bot pyramid.



Processed with VSCO with c1 preset

Event and reception:

The two products were presented in an open exhibitions. The interactive experiments facilitated discussion amongst different participants. Some instruction was needed to kick start the mapping process.

Surprisingly, the response to the first experiment was leaning towards robot-like representations. The basic figure of a robot was deemed more trust-worthy than other more human-like representation. This was particularly interesting since we thought that human-like characteristics are more familiar and able to work well in a team setting.

The response to the first experiment was more concrete than that of the second, where judgment was very subjective. However, the second experiment triggered a various arrays of discussion.  For example, a point was raised about the suitability of bots to bridge different cultures in a workspace.



We are the SCREAM TEAM. Through this blog we will keep you updated on the progress of our project.

This is us:

This is us!

Our project:

For the next few months, we have been tasked with developing a chatbot for the SCREAM! project. SCREAM! is a design method that is both app-based and web-based. It’s built to work with MediaLAB’s Design Method Toolkit and facilitates the SCRUM software development framework. A link to the app can be found here. The bot should be integrated into the app in a way that is cultural sensitive and interdisciplinary. It should be able to both guide and motivate users to document their design process. This comes with an array of unanswered questions about human-bot relations.

We are excited to be working on the SCREAM! project and hopefully we will be learning a lot!