The New Intelligence: Practice App was a thirteen week project that we undertook as our Studio 3 class project. Our team consisted of nine team members, those members were made up of four designers and five programmers, plus our two facilitators. Over these thirteen weeks we participated in extensive interaction and game design, design research, programming, internal and external collaboration, stakeholder meetings (communication), stakeholder training, mobile application development (building), and much, much more… this is going to be an analytical discussion into my processes and what my thoughts and revelations are, now that the project has concluded.
I’d like to start with stating my expectations for Studio 3 before entering the unit for myself. This is what I knew… the unit had something to do with mobile application development, well more importantly it was all about commercialisation. I could not have expected the opportunity to work alongside an external stakeholder that was asking for my services, that’s just something that wasn’t even close to my train of thought…
This project required us to work alongside an external stakeholder, and it’s been an experience like no other, and it won’t go dismissed. To be completely honest, it’s been an opportunity that I could not have imagined embarking on during my degree, at least not until I had completed my studies and gotten a job in the industry with a group that took on this kind of contract work. It’s been an insightful first hand experience, and a developed look into this avenue of work within the industry, and what that type of work entails and consists of.
Settling in and knowing that we were being contracted in as game developers by other people not from the university was exciting, but there was a level of seriousness about this situation. The bottom line is that New Intelligence approached us, and needed us to develop a practice application for their users, a serious game. They were already on board with the whole video game idea, so we didn’t need to pitch our services to them, they knew what we did and that’s why they approached us, for our expertise.
There’s a great comfort in being approached as a game developer, were you’re being considered as the specialist in the situation, and the ones approaching you realise that, it not only makes the whole process easier and more fluent, but it’s also a really great feeling!.
Communication was going to be a constantly exercised activity throughout the development of this project, and it all started with us meeting with the stakeholder face to face. We prepared as best we could, but I’ll be the first to say that I don’t think any of us knew what to expect from that initial stakeholder meeting – thankfully Claire and Greg of New Intelligence where lovely people and were easy to talk to. We quickly established a baseline rapport with the pair and found that Claire would become our main contact point for the running of this project, and that’s who we directed all of our further questions towards, she was also our instructor for the interview training course we undertook.
Designing for this project in particular, and mobile devices generally, was new ground for myself. In the case of working for someone else and not ourselves, we had to apply our design skills to the information that we were being handed by the stakeholder, and this came in the form of participating in their ‘Art of Interview Techniques’ training course held over 2-days in South Brisbane, exclusively for us and a selection of staff from SAE.
I found that integrating the design techniques I’ve picked up along the way here at SAE, to be an interesting application process, with handling more sensitive and serious information and data than normal, and in ways working towards applying a very “interaction” oriented approach to designing things that are meant to be played, was something that I had never undertaken before during my degree. I found that I’m more accustomed to applying my game design into the “building” phase of development, but this is heavily dependent on the time frame of a project I’m working on, and in the case of my university based projects they’re typically within a 2 – 6 week timeline, so this method of design makes sense for those… but this was a 12 week project, which allows for more development time than we’re used to.
However with a more delicate and thought through approach to game design needing to be taken on this project, that method of rapid and continuous design would need to be put on hold, and a more “heavy duty” design only focus would need to be employed not only by myself, but by the whole development team. Essentially we split development into the design phase and the building phase, both with a time weight of 50%, working out to about 6 weeks per phase.
In review I feel that all four of the designers approached the game design for this project not only professionally, but effectively. With an increased focus on the smaller details and the ethical considerations of the content we were handling, we approached mobile development appropriately and to the best of our abilities, both in presenting the stakeholders information in an effective and resourceful way, but also due to the fact that we were designing for a new platform.
We held strict documentation standards across the board, and especially when it came to our spreadsheet data (pictured above) that was being exported out into an XML format, and then being read into our unity project as our core content source, so these spreadsheets could not have a single fault. The usual culprit – our game design documentation – was regularly updated as best we could, but was unfortunately one of our biggest downfalls. The collaboration held between the design team and the programming team was held down by this document, so it was detrimental for it to have clarity and consistently accurate information for the programmers to refer to.
One of our biggest issues was that the prototype that we ended up creating for the app was made in a program called Marvel App, this was a fine way to showcase our prototype but it was the only place that this visual reference was being stored, and the programmers did not have access to the account we designers were using. This caused a variety of issues with the systems and tools us designers were being handed by the programming team, and it ended up being a case of the two teams having a very different picture in their minds of what this app was meant to look like, primarily due to different information and sources for visualization.
Looking back now, we should’ve realized this earlier and given the programming team a clearer picture of what this app was visioned to look like, at least give a clear representation of what us designers were thinking. Not to say we didn’t do this in some fashion – I mean the programmers did play test the prototype – but we could’ve included visual guides/ style guides in our documentation, even if it was just for clarity of mind.
Communication with the stakeholder was scarce throughout development on this project, and that was to no ones fault it’s just the reality of collaborative project work, but it did impact our timeline for the project in considerable ways. We developed a questionnaire that New Intelligence could send out to their customers (our target market) in order to gather information on what sections of the training our end users felt they needed/ wanted to practice more than any other sections, this was an attempt to identify what the users wanted from this application we were developing, but ultimately this fell short and caused us to lose a lot of development time.
Weeks went by with limited communication with the stakeholder after handing our questionnaire over to them, and we had just assumed that it had been sent out to their customers, and we were just waiting for results to be sent through… but rule number one should always be never assume anything. Due to this assumption, and later our realization after contacting New Intelligence via Skype and email, we found out that the questionnaire had never been sent out to the customers, and we were losing precious development time waiting on results that were never there.
In retrospect – we should have been doing this anyway – I feel that we could’ve started development on the application in engine at this time, and have been working towards having a functional alpha build together by the time we found out this unfortunate information. It’s in my belief that this would’ve proved to be a more beneficial use of that “waiting on results” time for the whole team, rather than our focus on documentation and design oriented tasks not that they were not important, but I do think that a functional build would’ve been more beneficial to us in the long run due to the amount of bug fixing we had to crunch through on weeks 10 – 12. If we had started the building sooner, maybe we would’ve sourced these bugs earlier, and maybe we wouldn’t have needed to do that bug fixing crunch at all… but who’s to say.
You could say that this has been a “good” experience to have during my university studies, as it’s a “real” insight into how these relationships and communications with client’s and stakeholders can play out sometimes. Looking at how lack of communication can easily impact the project you’re working on, and discovering how your entire project timeline can be changed dramatically in such a short space of time, and finally how it’s often something you cannot plan for but is something that needs to be appropriately considered.
Unlike previous projects I’ve been apart of, play testing was a curious undertaking, as we were handling information that wasn’t typical for student projects here at SAE (at least not in my experience). That made finding play testers not so easy, and in addition to these factors making it difficult to play test our product, potential play testers that we would find on campus haven’t taken on the training session we had – weeks prior – meaning that the information we would gather from testing would be very minimal, and solely related to functionality which was something we could better handle internally.
In light of this issue we faced, we opted for an internal play testing regime. This consisted of us starting to paper prototype our designs early on, and really that was something that we carried out throughout development (seeing as we had not started building in engine yet). For more information on our paper prototyping for this project, read this blog.
Essentially this method allowed us to quickly think of ideas, test them and then iterate on them, something that is lost in much of the building process. There was virtually no real time cost and no dependencies of needing programmers, software/ equipment, or external collaborators. This meant that when we started building in engine we weren’t going in blind, as we knew we had a solid design foundation formed and tested before building started. The flexibility that this method allowed us designers was invaluable and it’s something that I’ll employ on my projects and ideas in the future.
However, this does not come without a cost in my view… understand, that I’m not saying that us relying on internal play testing/ or paper prototyping was a bad method, because it was not, it worked for our situation and I can totally see the benefits in it especially when designing for mobile devices.
However, (reiterating my points outlined earlier…) I do think that it would’ve been beneficial to the project if we had started building in engine earlier than we had, mostly because we could’ve identified development issues earlier and addressed them sooner rather than later, and this likely would’ve allowed for more content to be in the final build we handed over to the stakeholder, rather than resulting in the need to cut content.
To wrap up my points above, this whole New Intelligence stakeholder project and really just the whole of Studio 3 has proven to be a real eye-opener for me in many different ways, in to many ways to start discussing right now and here… but don’t worry I’ll be getting to that soon, so until then! Thanks for reading!