Design brief – REDUX
Posted May 14, 2008on:
The design-brief as presented is a very general on ment to intrigue, and to “sell” the project.
I have made a more focused one, that constrains the amount of work a bit:
Design Brief for work on a camera for the game concept Chaser.
Title: Bikes´n Buttons
Background: Chaser is a game that uses Oslo Bysykkel (city bikes) as an infrastructure for play in the streets of Oslo. It is a game that is based on “manhunt” or “catch” It is a competitive game-structure based physical displacement off free-moving individuals or teams, and can have many different game-narratives and organisations (pursuit/catch, collecting/scavenging, search and destroy…) .
The games are organised around the system of the city bikes, that users subscribe to, uses freely for up to three hours and that is monitored by Clear Chanel as service providers.
The bicycles themselves are equipped with cameras, geo-location and network possibilities (chaseCam), and are as such to be considered as networked objects. Every bicycle has accordingly it´s proper identity recognised by the system.
The user decides themselves to participate in the game, on the street and the online game-community. All users are registered in Clear Channel´s system and have accordingly their proper identity that is monitored by the system.
The online game-community regulates the game and the players, and is an arena for sharing, conversations, reputations and relationships.
Problem statement: chaseCam is a networked camera placed on a shared bicycle. The bicycles are used by the public. Furthermore, the bicycles are left in a rugged, outdoors environment. The camera needs to be operated in (often) high speeds, in busy traffic. There lies two main problems in this statement:
- How does a camera survive the public domain?
- How do you trigger a bicycle camera in high speed? (The initial thought is a button on the handle-bar, but what does it look like? does it need to be a button?)
Deliverables: The project should result in several iterations before a final design. The final result should consider ergonomics, interaction and aesthetics. The final result should be “shelf-explained” and “productized” but a “commercially rational” product is not expected.