My colleague Jo Davies recently blogged about a new internal development project we’re embarking upon here in Boston and our longlisting / shortlisting process. (You can read all about that here in Development diary part 1 – sketches on a canvas.)

In part 2, I’m excited to announce that the winner is… FoosBot – congratulations Fil!

Foos what?

The FoosBot project will explore a variety of deep learning techniques to train a neural network – the “FoosBot” – to play foosball against a human opponent. Training will take place in increasingly complex virtual environments, with plans to transfer FoosBot to a physical foosball table in the project’s final phase, culminating in a demo that will allow users to experience deep learning through the game of foosball!

As technology consultants, we know all too well that it takes a lot to turn an innovative idea into an engaging product – or, in this case, demo! – that meets the varied needs of its users. Many important questions must be answered before we can draw-up the system architecture, such as…

  • How will people interact with the demo?
  • How will the demo showcase the machine learning aspect of FoosBot?
  • How can we design FoosBot to minimize technical risk?

Here at CC, we're firm believers in Human Centered Design, with experts such as Karen Unterman from our Human Factors team on hand to help us sort out these messy details.

The user is always right!

Karen has been helping us understand who our users are and how these users relate to the demo we want to create. Understanding users’ needs ensures that the end-user experience is not compromised as development decisions are made.

To gain an understanding of FoosBot’s users, we went through a process called ‘user story creation’, which begins with the construction of user personas. (User personas are fictional characters designed to represent a specific type of user who will be interacting with a system.) This helps us see things from the user’s point of view and understand their unique needs.

To do that, we identified the various types of users who will be interacting with FoosBot in different environments, such as potential recruits at a conference, or a client visiting our Boston office. We dove deeper into these personas by interviewing people who closely matched each persona profile.

During the interviews, we didn’t give the interviewees any specific information about FoosBot. Instead, we asked them about what motivates them, what they consider important, and what their frustrations and pain points are when working towards their goals in different scenarios (e.g. at a conference, during the recruitment process, etc.).

By the end of the process, we had fleshed out user personas for our four major user groups: the client, the business developer, the recruit, and the engineer / developer.

Everyone has a story

Once we nailed down our user personas, we got the team together for a brainstorming session. With our new personas center stage, we started thinking about what needs each one would have when interacting with FoosBot throughout the use cycle of the demo. For example, the business developer persona heading to a conference needs the FoosBot demo to be easily transportable.

By the end of the session, we had a board covered with user needs. We then distilled these down into more focused user stories, which are written in an “I want...” format. For example, the business developer’s need for transportability turned into the user story: “I want the demo to be transportable in a taxicab.”

Similar user stories were then condensed or weeded out, and additional user stories were added as new needs were identified. The process challenged us to think about how the FoosBot demo will address all the user needs, and we found that as we refined and solidified our user stories, our vision of the FoosBot demo solidified as well.

The road ahead

Now that we have our user stories, we can start on the system architecture and plan the phases of work that will bring FoosBot to life! As the system architecture takes shape, we’ll continue to check it against the user stories to make sure the FoosBot demo meets the varied needs of its users.

Tune in next time as we delve into system architecture creation!

Diary of a developer (part 1)
Diary of a developer (part 3)

Jay Biernat
Engineer, Wireless & Digital Services

Jay is an engineer with a passion for audio DSP (digital signal processing), to which he brings his experience in applied mathematics and music technology.