Running a Prototyping Sprint with BigDataOcean

At the BigDataOcean project kick-off meeting, several great challenges emerged for the project. This required the consortium to prioritize its actions and focus in on what is meaningful for the pilots, especially since the project runs as an Innovation Action in Horizon 2020, meaning that it needs to focus on releasing more “product-like” results. For this reason, in NTUA, we decided to test a promising and emerging prototyping methodology called “Sprint”, introduced by Google Ventures. The idea of the methodology is to develop and test a prototype in 5 days.

Of course, because of the limitations imposed by a EU-funded project, with partners all around Europe, we were not allowed to “go big” since day one and include every partner in the process; for that reason, we decided to “go Lean” and test it in smaller scale, measure the positive outcomes and the difficulties, and reconsider in the near future possible prototyping sessions in bigger scale. In this blog-post, we describe the process we ran, what the outcomes were and the lessons learned through our prototyping experience.

To give some background information, only members of the DSS Lab team from NTUA participated in this process, meaning that everyone had previous knowledge on the project and some initial work had been done individually. 7 people in total participated, all researchers on the team; nevertheless, diversity in the team came from the different perceptions and backgrounds of each team member, covering both business and technical expertise. The team did not book a full week; in order to test the methodology, only one day was booked initially. Because of time limitations to meet the project deadlines, it was decided to push two days into one, if possible.

Day 1

The team came together on Day 1 in order to define the project high goals and the sprint questions. The team followed the schedule, but because of its previous experience it ran faster than expected. By the end of “Day 1” we managed to design the customer map (see Picture below) and to describe the “Long Term Goal” and the “Sprint Questions”, which are:

Long Term Goal: EASILY CONSUME MARITIME (BIG) DATA

Sprint Questions

  • Will corporations be willing to share their Business Data?
  • Will authorities collaborate to make available their Data?
  • Who will curate the data?
  • How will the value of the datasets be measured?
  • Will the service be fast enough to cover users’ needs?
  • Will the users be able to find homogeneous data on what they’re looking for?
  • How do we ensure users keep coming after the 1st time (return)?
  • Will users trust us?

The team then went through the “experts” session, by going through all the pilot cases that had been presented in the kick-off meeting and had been described in the Description of Action. Then, the team initiated the “HMW” questions, refined the map, re-divided the stakeholders into smaller groups, and chose the question (i.e. “How will the value of the datasets be measured?”) as the most important to run through the prototyping phase and the step (i.e.”View Resources Preview”) to focus on (see red areas on the picture below).

The questions and the map that the team came up with

The questions and the map that the team came up with

As the team worked and prepared a relative State of the Art analysis, it was easy to go through existing solutions and have each one of us present what we liked from different solutions (see image below).

Topics the team extracted by relevant tools in the area

Topics the team extracted by relevant tools in the area

The team then was able to allocate who will design what during the ideation phase when different designs emerged. After assigning the members to different steps, it was agreed that the design round will run “offline”, before the next meeting. The next meeting was set for the upcoming week; the team left the room tired but contented with the outcomes of the first-day meeting.

Day 2

The second day started with the “Museum” session, where every solution was placed on the wall, and each one of us commented on them and highlighted the most promising ideas (see picture below). Then, “speed critique” took place, where the “facilitator” described what each design presented, and tried to answer the questions from the post-its. Each “creator” came up to cover all the necessary gaps, and the team then voted on the most promising ideas. The “decider” came up with the three most promising “screens” to implement on the prototyping phase. Those screens were:

a) A preview screen for the data with multiple tabs
b) A report-synthesis screen interacted with through tables of raw data
c) A report-synthesis screen to run analysis, enabled by a library of code

There were other different ideas and concepts that our team came up with: for example, an intuitive landing page with advanced search options, or a “requesting” page. Nevertheless, we did not take them into account in this phase and focused instead on how data review and reporting can engage users more effectively on the platform.

A design voted by the Decider

A design voted by the Decider

The team decided to implement the storyboard and the prototypes offline, and then visit the pilot users to test those ideas. Thus, the experimenting phase of using the “Sprint” methodology on a collaborative, EU co-funded project came to a close.

Overall

The team was tired at the end of the second day, but happy about the outcomes. Typically, our organisation engages its members through meetings, and then we assign individuals to design the mock-ups, and then we come together to discuss them. This was the first time where every part of our team participated actively throughout the whole process, and ideas that we would never have imagined came up (via the new prototyping methodology). The input for mock-ups is valuable, but still it should be communicated with the partners before ending up with an agreement.

Of course, there were many difficulties. It was hard for the team not to use its devices, and during the breaks we still kept working, answering emails even debugging projects. The team was reluctant in the beginning, but by the end was impressed by the outcomes and the usefulness of each session. The experts (i.e. pilots) could not be present in the meeting, as they are also the users of the platform that will interact with the prototype; nevertheless, we enacted a role-playing game and went through their presentations to break down their motives and needs. What the team really disliked initially were time limitations, and running “brainstorming” meetings in a timed fashion; surprisingly, the final outcomes were better than expected, and the team was tired (especially mentally) but excited.

A picture of our team in front of the “museum” wall, after the voting session

A picture of our team in front of the “museum” wall, after the voting session

It has to be noted that the prototyping phase was not completed, but now more people are aware of the advantages of this process, and in the face of upcoming challenges it will be easier to engage seven people in a full-week “meeting”. Adjusting also the methodology on partners in an EU co-funded project is even a greater challenge, with multiple obstacles to overcome (e.g. operational, organisational, geographical etc.). However, the first outcomes are promising, the team is feeling positive for the upcoming phases of the project, and we liked sharing with you our experience in order to change our state of mind around research and collaborative projects in Europe.

We will share with you the outcomes of our Sprint when they are available!

Comments are closed.