Final Changes made from User Testing

Feedback given

The feedback given was broadly positive; the app was described as fun, and well designed, and appropriate to the task. It was suggested that the vocabulary being used currently was too mature for the audience and desperately needed simplifying however. We had already removed the parts deemed too explicit for the age group during initial client feedback, so this was not an issue. It was suggested that we added in a transitioning effect for factual information that displays when the correct answer is chosen, with a timer, so that the user is more inclined to read the information instead of skipping through it.

Salient points to consider

Broadly speaking, we identified our current goals as making the content appropriate and readable for the age group, with a secondary goal of adding in a transitional effect.

Implementation of new changes

We reworded the content in order to appear more friendly, more readable, and with an easier vocabulary. We removed some of the more technical details of the facts, which had the added benefit of shortening the facts overall allowing for a bigger font to be used, adding to the appropriateness for the age range. The salient points within the facts still remained valid, and they were still relevant to the Magna Carta and cathedral. We were unable to add the optional features of reminding users to respect times of prayer, and transitional effects, due to time constraints and a need to prioritise project requirements.

The app was finished with final tweaks made to the design and layout, as well as sounds being added to accompany the new content. We checked the MoSCoW analysis which showed us that all priority features had been completed successfully, alongside many preferred and suggested features, as well as ensuring that we had not included features that we had justified not having.


Changes made in response to Client Feedback

Content changes from feedback

Age appropriateness

As per feedback from the client, we removed the references to the murder of Thomas Beckett, and the references to adultery within the monarchy, due to the inappropriateness for the age range. We plan to follow up assessment of age appropriateness in the app with user testing and gaining feedback from the education officer at the Cathedral, and a primary school teacher in order to ensure the content and mechanism will work well with the age range.

Storyline/Narrative structure (sectioning)

The introduction of more characters and more tangible features of the Cathedral, to replace previous ideological or historical concepts meant we could now section the content in the application into characters of the Magna Carta legacy, and features of the Cathedral. Introducing this change allowed us to improve upon the narrative of the app, which was supported by the mascot we had designed. We updated the dialogue of the mascot to support the new changes in content.

Content changes

Visiting the client for a meeting also meant visiting the cathedral, and doing so alongside the client offered the chance to look for more inspiration relating to the creation of content. Looking around we found a lot of inspiration for content which we built into the app by means of new questions and factual relevance to the cathedral as a historical building. As a rule, we ensured that our new content as a result of this was less ideological (such as looking at the introduction of Trial by Jury influenced by the Magna Carta) and more tangible, which not only facilitated a connection as something that could be looked at, found, or touched, unlike more ideological or historical concepts, but also meant it was better understood by the age range.

The expert knowledge of the client helped us to produce content that may have been harder to create relying solely on research; we were able to include lots of anecdotes and quirky stories relating to the Cathedral and the Magna Carta legacy. This primarily involved looking at architectural features with a story or rationale behind them, and we were able to forge a link between including these in the app, and encouraging the user to go and search for these parts of the cathedral – categorically introducing a strong connection between the user’s experience of the app and the building itself.

Sound style changes

We chose a selection of less ambiguous sounds that we feel can instantly be understood as to what the sound is of, and thus returns the user to the main challenge of the mechanism of deciding how the sound provided in the app is relevant to the phrases provided as answers and explanations of the sound being played. However, looking at new sounds required ensuring that the copyright was suitable for our planned usage. The sounds chosen were all available under the creative commons licence, for non-commercial usage, with attribution, however we have submitted these details to the RedBalloon legal team for confirmation before we implement them into the project.

Proposed User Feedback

In order to ensure that our current prototype was appropriate for the age range we conducted some user testing by asking the education officer from Salisbury Cathedral, and a primary school teacher, for their thoughts on aspects of the app.

We submitted a video of the prototype in action and asked for feedback on the app as a whole. We explained what the video showed as well as a brief summary of our intentions, in order to make it possible to gauge the prototype against our intentions. We explained also that, since it was a prototype, there were small quirks in the design and layout at times, in order to avoid feedback on issues we were aware of already.

We chose the people we did for feedback as they were professionals in the field relevant to us, and had a broad understanding of the age group due to working with them frequently. We did not ask for feedback from the actual target audience due to logistical issues with being able to find and survey a group of 7-10 year olds as well as a potential inability to provide feedback for the higher level concepts we were still in the process of exploring.

We asked for feedback on how the idea would work in general for 7-10 year olds, and specifically on the mechanic of the idea, whether the user would be able to work out how the game operates, the content itself, and the general concepts and ideas explored. We also asked for any suggestions in terms of features or content.

We plan to use the feedback in order to inform the final design iteration of the application before we release it, and as a confirmation that the final build is appropriate for the audience we plan to have use it.

Client Feedback

Having evaluated that our workflow and process for development was working well, having discussed with both RedBalloon and the rest of the team the current stage of the project, we thought it would be a good idea for me to go to Salisbury and visit the client in order to gain some feedback on the content and mechanism of the application, as part of the critical final evaluation suggested by RedBalloon. We planned to consider the feedback given to us now to be crucial in realising the final release of the app in 4 weeks.

Feedback given regarding mechanism

Feedback given regarding the mechanism of the app was broadly similar to that given by RedBalloon; the client was happy with the proposed design regarding how the user would interact with the concept, and all three parties agreed that the concept was driven mostly by content – including the sounds, the answers, and the factual relevance.

Feedback given regarding content

The client suggested a variety of points for feedback relating to the way in which content had been produced;

  • Make the sound clues more literal and less ambiguous, for example the use of animal sounds, action sounds, or emotional sounds. Be specific with aims of the sounds used. We interpreted this as the use of sounds in a more direct manner, for example, to cause the user to not think “what sound is that?” but to think “how is that sound relevant”, as to avoid a breakdown in interaction between the user and the app, caused by ambiguity in sounds.
  • Link facts to the exhibition, the Magna Carta, or Salisbury cathedral specifically. In order to continue a close adherence to the initial brief we needed to ensure that aspects of the app were closely linked to the subject matter – it was suggested that we achieved this by prompting the user to go and explore an aspect of the physical experience with a prompt in the facts delivered by the app; for example suggesting they search for a tomb upon correctly answering a question regarding the passing of a key figure.
  • It was suggested that we needed to ensure we made content appropriate for the target age range alone by ensuring content was not too explicit or violent and sanitising the aspects of history we had drawn upon with some discretion to make it suitable for the age range.

We took away new intentions for the final iteration of development from this feedback, which was very helpful in refining our final tasks for completion of the project. Our new priorities included fostering a strong link between the general narrative of the concept to the exhibition, the cathedral, and the Magna Carta in order to better meet main points of the brief. In addition to this we had to focus on the coherence of sound effects and the content itself – both in its feasibility and relevance, and in its appropriateness for the age group.

Evaluating the Workflow

With 4 weeks left before the project deadline, evaluation of our workflow and documentation strategy was key. Having a robust system for workflow is important, since in the industry if another team were to pick up the development of a project from where it had been delivered previously by another team, they would need to be able to know how the old team were working in order to best continue developing the project. This includes having complete access to all original assets used in the project, all notes, documents, and blueprints, in order to build a comprehensive picture of the original development strategy and be able to build upon this.

Achieving this state of overall project comprehension is a key reason for why documentation is so important – if every step of the development process is documented, for example – considering why a decision has been made, or why a feature is not implemented, how a feature is to be built, etc, then a new team can easily build an overview of the process and save time in knowing what has already been tried and explored before by a previous team. Additionally, documentation of prior development helps when planning further development on a project as additions can be built to be easily implemented in with the old ones. This would also include information like program versions, as there is differences between older and newer versions of SWIFT for example (cite?), file formats, and other format specifications – such as the resolution for images and videos.

Finally, the systems used for workflow and documentation need to be accessible and translatable in order for the new team to make use of it. A proprietary system for workflow may have benefits in terms of flexibility and privacy, but it needs to be documented well enough for the new team to make use of it. Alternatively, it could be argued that such a system may have disadvantages as it could be difficult to implement this into a new system. Documentation needs to be carried out in a systematic manner, which is easy to read and access – through a type of hierarchy or signposting.


File/Asset management

We had originally opted to use our MediaWiki to host files as it was adaptable, permission-controlled, and also hosted the rest of our main content for the project. However, we eventually switched to using Google Drive (cite) to host the asset files for our project, as we found that use of the MediaWiki as a main channel for quickly sharing files did not work so well; it was lengthy to access, supported a limited range of formats and had a poor system for indexing and accessing uploaded content. Arguably, this could have been remedied for longer term usage with custom modifications, plug-ins and other changes however this was potentially not appropriate for the situation at hand. Changing to Google Drive allowed easy upload and access of files due to the well-designed interface, worked natively on a variety of devices held by the team allowing ubiquitous access to files and assets as needed, and its position as a standard service meant that the team was already familiar with its usage, unlike the wiki – for the purpose of sharing files. We also found ourselves employing other methods such as USB sticks, email, and direct file transfers for more acute, situational usages, where appropriate.


Primarily we communicated in person through arranged working sessions, however outside of this we used a private group session on Facebook. For similar reasons to Google Drive, we opted to use this as it was again, permission-controlled, offered a lot of very useful features, and most importantly was very already ubiquitous in its implementation. We all had Facebook integrated with our phones, laptops, tablets, and various other devices already, being frequent users, and we feel that this perpetual contact offered significant benefits for the project in terms of frequent, short progress updates and the sharing of minute details regarding the project which helped greatly in minimising gaps in communication. Due to the relatively un-indexed nature of communications on Facebook however, we also made good use of a page on the Wiki to post important updates and synthesise meeting notes to provide a steadfast central position from where the most important issues could be made clear to the team. We conducted the vast majority of project-defining decisions through once-weekly meetings and group working sessions which we conducted multiple times a week.


Task management

We continued to use Trello as an online SCRUM board equivalent for the duration of the project to keep an overview on tasks in general, however made use of various pages on our Wiki to discuss semantics, such as what was happening on a day-by-day basis. We designated tasks to ourselves and each other which worked well as it beckoned an element of responsibility and accountability, meaning tasks were completed on time as expected. This also helped us in knowing what tasks were in progress, and how, and when, targets would come together.




We documented meetings with the project manager using OneNote (cite) to quickly make notes of what was said throughout each agenda. This allowed for indexed, hierarchical, and accessible notes to be produced, which were then synthesised onto the Wiki and distributed to any other necessary channels, making changes to layout and content in order to improve accessibility for other team members. Tasks for the week were distributed to a page on the Wiki and to each team member, and client feedback was delivered to relevant areas (dependant on where the feedback was directed to) in order for changes to be made.

Project notes

We used a system of making notes individually, on the task at hand, which would then be discussed at team meetings if need be, or developed into fuller documentation on the Wiki. The Project Manager would collate any notes and thoughts into relevant areas on the Wiki for easier access throughout the duration of the project. Notes were also developed into fuller documentation to keep a development log of blog posts regarding the project on WordPress.

Working documents

Working documents were developed using software such as Microsoft Word, Calligra Words, Word Online, OneNote, Google Docs, and similar packages for their superior editing and proofing tools compared to the plain text entry used by the MediaWiki software, and then transferred to the Wiki when finished in order to make them easily readable and accessible for all members of the team, as a central part of the project. The Wiki became an invaluable cornerstone for documentation of the project as a structure soon developed listing all initial resources and assets from the client, the University, and individual contributions by team members including working documents from which features would be built and assessed, as well as documents showing content for the app, contact details for team members, roles, documentation for the use of the Wiki itself and to-do lists.

Easter Progress Report

Meeting with RedBalloon

We were now well underway in the design process of the app, and felt it appropriate to organise a meeting with RedBalloon for an assessment on the progress of our project. We discussed the need for a functioning prototype to evaluate, as a basis for looking at what needed changing or modifying if need be. Overall the feedback we received from RedBalloon on our application was that the mechanic we had opted to use, of a sound being played, and matched to a multiple-choice answer was appropriate and well-suited, but we needed to ensure the content was relevant and well-designed as the idea was primarily content-centric. We noted this as a priority for development and decided it could be checked by user testing with relevant professionals for our demographic – a primary school teacher and the education officer for the cathedral.

Additionally, one of the main needs for a basic functioning prototype was to organise a meeting with the client and present the prototype for feedback which could then be incorporated into the next iteration of our design. Discussion of the project with the client would help us to see what still needed work on in order to meet the needs of the client and ensure we were headed in the right direction – as well as to make use of any ideas suggested in the process.

Lastly, we discussed the need for user testing of the prototype, in order to ensure it was suitable for the target age group. It was suggested that this could be achieved by meeting with the education officer at the cathedral, who dealt typically with school groups, in order to assess and discuss the intentions of the project and its current manifestation for suitability with the target demographic. We also planned to get into contact with a primary school teacher for a similar style of review as a form of user testing.

Ultimately the project had now reached a breaking point most important, with 4 weeks to go, where we needed to assess the upcoming prototype against the original MoSCoW analysis in order to ensure we had met the criteria set out, as well as the criteria set by the brief, and the client. We would look at the mechanic, by discussing it with the client and other parties involved, and decide whether it would work for the final build in its current iteration. We would do the same for the style of the content – as we needed to start making definitive changes and finalising aspects of the project, and anything that needed changing would need to be done so now.

We also identified a few potential issues at this stage of production – we had to address issues with a potential data cap for apps accessed via a mobile network on the iOS system, as well as fidelity of the content. We still needed to implement progression and narrative system into the app to instill some emotion and sense of achievement, as per the MoSCoW analysis.

Our final priorities for the development of a finished prototype were to source sounds for the content, complete a successful JSON database for the integration of content, re-word some of the content, test the prototype on an iPhone to ensure that it works as intended on a physical device, as well as develop final broader priorities for the final 4 weeks after a prototype had been developed and checked properly.

Annotated MoSCoW Analysis


Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.

Sounds to describe phrases must be of high quality and clearly audible for the user, and should not breach any copyright or intellectual property laws

Sounds being played to the user is an integral part of the concept and so is deemed absolutely necessary to include in the final build. The sounds must be high quality to the point they can be clearly heard by the user to offer both a solid user experience and to not detract from the mechanic of the app

Sounds must make sense in their connection with answers, and relate to corresponding phrases through use of word-sound association as per detailed in examples

The main mechanic of the concept revolves around the connection between the sound effects being played and the phrase that they correspond with – so the logical link between them needs to be feasible and make sense, else the concept falls apart, and the concept breaks at this point, as the user will not be able to make connections.

Sounds and their connections with answers must elicit relevant information to the magna carta history, and legacy as per the current part of the app, and with appropriateness to the target demographic group

The brief states that there must be a close connection to the Magna Carta as a general concept – therefore it is imperative the factual elements of the correct phrases elicit accurate information in order to meet the brief. The factual information must also be understood by the target demographic.

Sounds must be able to be manually played by the user with the option to repeat if needed

Users must be able to repeat the sound if needed, as they may require a second guess or attempt at listening to the sound in order to confirm their choice. This is a must, as the user may otherwise get stuck and not be able to move on through the app.

The app must save progress on closure automatically, requiring no input from the user to do so, and be persistent during total closure of the app, or shutdown of the device

The persistence of user progress on app closure is a must-have feature as failure to do so will likely cause the user to not want to use the app, as they will have to repeat questions in order to achieve their previous score.

The app must offer the choice of three different answers to the sound combination, of which one is unequivocally correct and two are incorrect

When the correct answer has been chosen there can be no debate as to why it is correct, and the others are incorrect, as this will cause the app to appear to lack integrity. Likewise, more than one correct answer would go against the central concept of the mechanic and multiple-choice quiz conventions, and will be confusing for the user.

The app must include a separate view in which the relevant fact or info is displayed for the correct answer, and be of a legible font, colour, size, and arrangement

A separate view for the facts being revealed after choosing a correct answer is key, as they will not be able to fit alongside the content already being displayed without resulting in an unclean interface and composition, producing a poor aesthetic for the user, potentially dissuading them from continued usage of the application. The font must be legible in all sense of the term in order for the user to easily read, and make use of the information supplied.

Graphical elements and the design of the app must be adaptable and fit on all proposed devices properly.

The visual design of the application must be adaptable – as per the brief, the final product will likely be adapted by a senior designer in order to be built into a large application framework for final release to the client. The graphical elements must be easily adapted to the brand bible supplied by Haley Sharpe design, and the components must fit on all proposed devices in order to avoid incompatibility which could render the app dysfunctional.



Represents a high–priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

The mechanics of the game should be self-explanatory and easy to understand through the use of appropriate design cues, visual hierarchy and consistent graphical elements

Self-explanatory mechanics are an ideal feature to have in the app, as it is reasonable to assume a well-formed connection with the game and the user will improve engagement with the concept as a whole, however should this not be included the user can still refer to instructions in order to learn how to use the app.

The app should suggest to the user, or prevent the user from, playing sounds during prayer times at the cathedral, taking care not to sound patronising or offensive, perhaps through the use of looking at the system timer and displaying a relevant message

This feature would be useful to have included as it shows an element of responsibility in the production of, and encouragement of using the app as well as showing awareness of the environment, however the creators are ultimately not responsible for the ways in which users make use of, and the times they use, the app as there are too many outside factors that could circumvent this, including, but not limited to, other applications available to the user in the final product.

The app should have a clear visual sense of progression narrating the structure of the game

This element was suggested in a sense through feedback from the client and university staff – that there should be an emotive element to the game. The inclusion of a progressive narrative through the application helps to reinforce the concept of a storyline to the user, and fosters connection with the subject matter.

The incorrect answers offered should be feasible, and/or believable as correct ones, in order to provide a challenge to the user when selecting a response

If the incorrect answers available to the user are completely, unequivocally wrong due to an obvious tone of speech or subject matter, in stark contrast to that of the correct answer, then it could be argued the content would offer no challenge to the user, and potentially no hook to keep the user interested due to a lack of challenge.

The app should explain how the sounds provided result directly in the correct answer as opposed to the incorrect options through literal description, or potentially synchronised animation with the sound clips in the “correct answer” fact view

Including this feature has the benefit of explaining to the user how the connection is formed, which could in turn elicit a type of rationale the user could apply to following questions, in order to better understand the mechanic and the process through which the sounds have been matched with the answers.



Describes a requirement, which is considered desirable but not necessary. This will be included if time and resources permit.

The app could include a mascot character narrating the playthrough if it appeals to the target demographic, which can be explored through user testing prototypes with said demographic or looking at available research

The inclusion of a mascot would add greatly in terms of emotive appeal and the support of a strong narrative in the app, however is not strictly necessary and this could be achieved in other ways. The addition of a mascot would however be highly beneficial to the value of the app, if time allows this.

The app could include a view showing instructions explaining the mechanics of the game which would be clearly legible and in line with other graphical elements of the game, providing a succinct yet helpful tutorial on playing the game

The mechanic chosen for the game is categorically self explanatory due to the nature of the quiz format being used as well as visual hierarchy and user cues that will be naturally picked up on – however if time allows, the addition of an instructions screen will help to engage users and ensure that full understanding of the concept is achieved.



Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

The app wont rely on QR codes as previously discussed due to adding a further layer of complexity and possible issues with architecture in the location

The base mechanic of the application is standalone and the content is not contextualised in an explicit sense that requires QR codes to be attached to the environment. This can be ruled out as a feature due to the sensitivity of the environment, also.

The app won’t be geolocated in the environment as previously discussed due to possible issues with GPS in the cathedral and a lack of necessity for the current feature set

GPS requires a view of the sky to work correctly and/or accurately, and the application has been designed with this in mind. While the concept could be adapted to make use of GPS, it would add another layer of complexity that could block engagement between users and the main intentions of the concept.

The app won’t have a unique or irrelevant visual style in order to remain adaptable to other apps and the design guidelines

As previously stated, the visual style must be matched to the Haley Sharpe design guide as per the brief and client’s wishes, as well as to ensure maximum cohesion with the other aspects of the project as a whole.

The app will not be available in a landscape orientation, due to the lack of content that affords this, and the types of usage by the user that might require this

Landscape orientation compatibility will not be built into the application as a form of usage sanitation, as the content will not be best suited to a landscape orientation and there is no need for the layout to be adaptable to such, for this particular application, as it will offer no salient benefits for the user.