Summary
The group project module tasked us with creating an installation that people could use without the need for instruction.
We decided that Texting and Driving was a big issue that we wanted to tackle, so worked in an AGILE way to develop the Don’t Text and Drive simulator. The car booth was constructed and we created a working steering wheel with the use of an Arduino. The project got the best marks out of the year group.
The Brief
For this assessment you and your group will develop an interactive media installation for a public showcase. The exact nature, and interpretation, is up to each group, however there are some key requirements:
- It must be possible to physically install in a public space.
- It must be usable by members of the public with no instruction.
- It must work without an operator being present.
Ideas
Initial Conversion
We originally decided that we wanted to work in an AGILE way, putting into practice the lessons that we’d learnt in Web App Development and UXD over the course of the year. The group decided that this would be a good idea and would help to make sure that we’ve got a great working product at the end of the project.
Role
One of the first things we talked about in our first meeting was the roles that we were going to take on. I nominated myself for Project Manager and explained to the group my plan for working and developing our project. The group were happy with this and we went about setting other members of the team different roles.
Once roles were decided within the team, I proposed that we work in an AGILE way. I took on the role of scrum leader and we discussed how we wanted to deliver the project. We decided that with the 10 weeks we had, it’d be best to dive straight into developing a simple version of our project, getting to a point where we had the core gameplay, the adapting our method to a more AGILE way.
Branching Discussions
The group decided that change of law in March 2017, regarding the penalty for texting and driving, that it’s still something that’s going on and people think they can get away with it. We thought that this was something that we’d like to create a piece around to raise awareness that it’s very dangerous and isn’t as simple or easy as people thing.
Design
Concept
We wanted to create a solution that would be a simulation, created in Unity, that would be impossible to complete. The simulator would be from a first person perspective, in a car, travelling straight down a road. The road is littered with obstacles and it’s up to the user to avoid them, being able to steer left and right. The user is forced to text and set intervals.
The texting element of the simulation requires the user to press the correct buttons on the controller, as prompted on-screen. Pressing all of the correct buttons will complete a text and send it back in-game. While the user is having to text, the camera in-game will turn away to look at the phone. While the road is still visible to the user, it’s a lot more difficult to accurately see the road and continue driving at the same time.
User Journeys
We set out thinking about who we wanted to design the solution for. The group decided that we would want to target our system at younger drivers, those that had just passed their test. We found through statistics that these were the most likely to text and drive.
We did some user research and put together some personas and user journeys. We wanted to really understand our target users, as well as what would work with them. We knew that the key to making a simulation that would affect users’ way of thinking, was designing the simulation around them. We storyboarded our solution and set about designing our project to meet this.
Development
We dived straight into development, splitting the team into design and technical. The design side spent the initial 2-3 weeks creating basic models of all of the objects that we thought would appear in game, with the programmers creating a very basic version of the game. The basic game created featured a car going down a straight path, with randomly placed objects, the user could steer the car with the arrow keys.
Upon completing this initial work, we changed our focus to an AGILE way of working. We decided we would work in week long sprints, setting out the goals for each sprint at our weekly meetings. We would also be able to review the previous sprint at the weekly meetings and these would help feed our objectives for the upcoming week.
It was also during development we found that we were coming along well compared to our initial timeline. One of our designers, went away and looked at a lot of arcade booths and physical games. She came back and showed us her design, a physical car booth, which would help to make the experience a lot more immersive We also decided to create a steering wheel with the use of an Arduino that would allow the user to control the car in-game.
Conclusion
The collaborative process on this project was so enjoyable and I loved the evolution of our idea. It went from a simple simulator on screen, controlled with your keyboard, to a full car booth with steering wheel controller. I learnt a lot from our way of working and managing a team.
I’m glad we tried working in an AGILE way, I think we got a lot of value from working the way that we did. By building up to a point where we thought AGILE would be the most value to us really helped and made us feel like we were always doing things as it was the best method, not just for the sake of it.
Another thing that worked well for us, was the roles we set out at the start. We didn’t start by setting out specific roles there had to be in the team. A lot of what we did was based around what people wanted to do and what they felt most comfortable with. Obviously, with being a University project, there was a lot of freedom with what roles we wanted to take on, but it allowed everyone to work to their strengths, on areas that they enjoyed.