Our startup has its roots in the graduate project of De Monsters: Paul, Erik & Ferdi (hence the working title PEF). We graduated on the work and research that we did for PEF with an MA in Interaction Design at the Utrecht School for the Arts in the Netherlands. During your graduate year at the Utrecht School for the Arts you get eight months to come up with a project definition, do research for it and show its potential with a prototype. That basically is the briefing, not a whole lot to go on. There are a ton of things you can do if you have eight months to spend on anything of your choosing, but deciding how and what we were going to do with those eight months was quite a challenge for us. In this post we will focus on how we did this.
The main challenge for us in this project, and I think in most projects like this, is that we had a number of very different yet vital roles to take upon ourselves. Besides being the designer for the project, we were also stakeholder and in our case also the user. This is both a blessing and a curse as these roles can have very conflicting goals and interests. In theory this situation sounds ideal as you should be able to perfectly align these different roles. In practice it is not, in fact it can be quite hard to get a clear understanding of what your schizophrenic self actually means and wants. The starting point for us was to set a list of basic guidelines:
- We are part of the intended user base
- The product should be a starting point for other interesting projects
- The product should be ready by September 2008 and be in beta by July 2008
- The product has to be presentable
- Level of success has to be measurable over time
- An established working method is to be used
- The product should be an online product but it is important that it has an application feel
- Keep upscaling in mind. (This was added after we had some good discussions with our project counselor David Garcia, currently Dean of Chelsea College of Art & Design)
While these guidelines did not define what we were going to create, it did close off a whole range of possibilities, making it easier to select a focus. When we formulated this list we did so from a stakeholder’s perspective. As mentioned before this was only one of the roles that we had during the project, but the goals that you set as a stakeholder have a big impact as they define the main boundaries that you have to work in as a designer.
To make sure that we did not influence each other too much with these goals we decided that it would be better if we created them individually. We wanted to know our individual expectations and goals, so we created a set of questions (download in PDF) that an independent individual (thank you Marijn Laming) could use to interview us. While the questions were very basic, the interview setting allowed for a lot of free roaming for the three of us. Marijn did an excellent job at asking relevant questions that made us think hard about what we actually wanted from this project. It resulted in a long list with goals and ambitions from which we extracted the main goals that were listed above.
Working as a team
During the first weeks of the project we put a lot of emphasis on the team aspect and how we saw ourselves as individuals in this team. While this is always important, in this particular situation we believed it to be more important than ever as our supervisors had to be able to evaluate us on an individual basis, you simply can’t graduate solely on group results.
So to kick off our project and get to know each other even better than we already did (we have known each other for four years now and have worked together on various projects), we made a short trip to a peaceful, quiet and inspirational environment: Austria. The 450 years old place we stayed at doesn’t have a TV or internet, combined with the good beer and nice snowy weather this was a situation where we could really kick start the project. A lot of the material that is discussed in this article has its roots in the four days that we stayed there. It was such a good experience that we repeated it last December to define a strategy for the coming year.
One of the key results of the trip to Austria was a list of guidelines that we set for ourselves to help us is our design process as a team. The main goal of the list was to make sure that we knew where we stood and were able to understand why we made certain design decisions without having to go over them endlessly. The list looks like this:
- The state of the design should be visible and understandable at any time
- Make sure the entire team has overview of the project
- We should be able to compare different iterations
- There has to be insight in the knowledge that we gather
- Knowledge should not be lost along the way
For those of you who know what the prototype of PEF is all about, some bells may start to ring after reading this list. In fact we discussed these points at great length and were going back and forth on how we could make this happen. Our conclusion was that while it was possible, there weren’t many tools available to assist a design team with these points and that it would pose some very interesting challenges to overcome if you wanted to design something for this, a challenge we were looking for. For us the decision was an easy on to make, we would focus our project on coming up with a product that would support this list of goals.
At that time we had already decided that we would use a user-centered design approach and more specifically: Goal-Directed Design by Alan Cooper. To further determine the scope of the project we added another set of goals before we actually started our user research:
- Users should be able to have different backgrounds, goals and views
- Communication of design between different agencies/companies should be as efficient as possible
- The product should give insight in ideas
- The product should give insight in expertise
- The product should help to collect knowledge on design
- You have to be able to share individual knowledge
- The product should give insight in the flow of projects
- The product should help to show focus in projects
- There should be efficient use of prior knowledge, no blind copying
Combined with the guidelines that we set before, this gave us a clear enough path to start with our user research which we will cover extensively in future posts. For us this meant that the project finally was kicked into higher gear, but looking back at those first weeks, they have been more important than we realized at that point. Starting up a new project is never easy, but the structured approach and explicit definition of goals and expectations helped us a lot in getting it going.
What are your experiences with starting new projects?
