Introduction
Background on company
Hello Games is an indie games development company based in Guildford, UK. The company have been producing games since their founding in 2008. They have had no flagship titles, expect for their recent venture, the procedurally generated space exploration game, ‘No Man’s Sky’. The game was considered one of the most exciting and promising games to be released in recent years, even though it was not a fully funded, multi-national gaming company creating it. The journey from announcement to release day, the game was promoted by Sony, building up the hype surrounding it beyond what was expected. Post release date, and almost two thirds of their fan base have turned against ‘No Man’s Sky’. Arguing that the developers had given them false promises and complaining that the game lacked in features and things to do.
Part of why the fans are so angry is down to the fact that the developers and CEO of the company (also a developer), gave the fans no explanation as to what was going on. The developers kept asking fans to be patient, yet they were not giving them any information or reassurance for them to listen. At the time of writing, its been 3 months since release. The developers have not said anything on their social media accounts or the official game website addressing the situation. Miscommunication, or lack of communication has led to the near abandonment of the game by fans, which is why it is clear that the company needs to reach out to them.
Analysis of the Current Solution for user-based feedback
As mentioned above, the developers are currently incognito. They have had many opportunities to listen and act upon the feedback of their user base, but have not yet made any significant strides into coming back from the position they have put themselves in. The ways in which the users have been expressing their concerns and suggestions, are mainly through online threads dedicated to the game. Based on the threads, there is a large community of users who consistently talk about the new features they would like to see. As well as this, countless discussions about the game and the users’ experience which engage fans with one another and further immerse them. There is also a significant amount of users who are not happy and use the threads as a way of venting this anger. It is clear that it would be in the interest of the users to create a platform that is more helpful than the online threads, which have virtually no connection to the developers. The community that has formed whilst making their complaints/suggestions, is run by the fans rather than the developers. As for the developers, beta testers are their main source of feedback on gameplay features and issues, they claim there are many more features to be added into the game. A claim which has been keeping fans waiting since before the game was even released.
Proposed Solution
The methods currently in use might be effective in the release of a game by a large corporation. But, the size of the studio, how unique ‘No Man’s Sky’ is and the current situation the developers have put themselves in, traditional methods will not make a difference. Currently, the only way out of this loss of faith from the user base, is by communicating and acting on their feedback. There are methods in which developers can literally harvest data from within the game. Telemetry data from actions completed within the game are used to program levels and objectives accordingly. This is useful when developing content or when developers want to know specific things about a certain area of the game and how they can improve on it. But it does not give any context about user opinions or their suggestions. They have the data to make the alterations, but most of the time they work off assumptions and contextualise the data themselves or based of their predicted user base. Since this has not been sufficient so far, we are proposing an app to address these issues. It will be the hub for user-based feedback on ‘No Man’s Sky’ for the developers, for the users, it will be a way to interact with developers, access technical support and contribute to the games development process.
This app will be a place where users can provide bug reports for debugging, bugs throughout the game with the context in which they occur, questionnaires will be provided to gather contextual data about certain aspects of the game, and offering users a chance to have their say in what features will be implemented next within the game. The app will be dedicated to ‘No Man’s Sky’ and the Hello Games developers.
There are no other rival game developers using this method. There are websites and solutions to get feedback for your game/app from developers. However, developers fall into the category of ‘expert users’. In his book, ‘Simple and Usable’ (Colborne, 2010), Giles Colborne separates users into 3 main categories; the expert user, the mainstream user and the willing adopters. To sum up each user description; the expert user is one that is enthusiastic about new technology and use applications and programs as efficiently and often as possible. The mainstream users make up most of the user base, using technology solely for its practical uses and will most likely use the easiest program to get their head around. Finally, the willing adopter, they most likely use comparable products but want to utilise more functionality without having to learn things all over again.
These user groups will aid the process of determining how the features are implemented. Basing a feature on the expert user base would be a wrong move, as the majority of users would not be experts and would find the features complicated and clunky. This is why basing them around mainstream users is often the smartest choice, as it represents most of the user base for technologies such as mobile applications. This basis can also be used when determining which features would more likely catch on with certain user groups. If trying to please all of the users, an application could for example have different operating modes such as basic and advanced. The former being a washed down, simple interface whereas the latter could be an advanced interface, giving users more control if they desire it.
The methodology being used for the project will be the Lean UX methodology. The following excerpt outlines its use; “The ultimate goal of the Lean UX process is to produce as quickly as possible and with the minimal resources a product that satisfies customer needs. This means avoiding a lengthy specification and development process that eventually leaves the user unsatisfied.” (Liikkanen et al., 2014). By using this methodology and focusing on the users needs rather than creating unwanted features that would bulk up the app with no positive outcome.
Problem statement
Following the assessment of current solutions to the problem that the business is having, a problem statement was created;
Assumptions
After considering the problem statement and dissecting it, the following list of assumptions were formed;
A1 – Our customers have a need to express their suggestions and feedback to help create a better user experience.
A2 – This need can be solved by creating a platform (an app) for the user to give constructive feedback whilst also aiding in the future development of the game.
A3 – The customer base we are aiming for is the existing players as well as players who have stopped playing the game over time.
A4 – The opportunity to choose the upcoming features of the game will give the user a sense of involvement in the development of better features.
A5 – We will provide the necessary features in order to keep the data relevant and constructive.
A6 – This app will inevitably help improve the game as well as keep the user numbers high.
A7 – This solution will provide a better connection between the developers and the user base.
A8 – The community of users that are still playing the game will respond in a positive way.
A9 – The biggest product risk is the minimum engagement of the users with the app, which would make the application unsuccessful.
These assumptions will be used later on to create a hypotheses statement. This will be useful to create features specifically tailored for each assumption, as well as making sure that the features being rolled out are in correlation with the prioritised assumptions.
Prioritization Matrix
(Format Source: Lean UX, 2013)
The prioritization matrix visualizes how much risk lies within a given assumption. By doing so, we can prioritize certain tasks that are dependent on the assumptions that lean towards the high risk area of the chart. The assumptions will be prioritised in the direction of the arrow. This way, the assumptions within the red circle, which are the ones that are high risk and therefore will be the highest priority, next will be the assumptions closest to the circle and so on.
Hypothesis Statements
The prioritised list of assumptions can be used to create hypotheses statements. These statements can be utilised to minimise the risk of the assumptions by stating how a desirable outcome can be achieved, as well as stating what will be the judge of whether the assumption is valid or not (Lean UX, 2013). Below are the hypothesis statements in order of importance. The assumptions chosen are from the prioritised list of assumptions and ones that indicate a feature is required to make sure the assumption can be fulfilled.
A9 – We believe that the engagement of the users is critical to the success of the app. We know we are right due to the fact that the app is based around the users’ engagement and feedback on the game.
A1 – We believe that the users have a need to express their opinions and suggestions for the game. We know his from previous market research and will utilise it when we see the feedback provided by users after the app is released.
A7 – We believe that the release of the app will bridge the gap between user and developers. The validity of this will be measured by how many users use the app as well as how the developers respond to the feedback given to them.
A6 – We believe that the app will work to improve the current game and raise the number of active users using the game. We will know this once the app is released and we receive feedback from the number of users online.
A5 – We believe that by keeping the methods of feedback sufficient, it will help improve the game significantly. We will know this when we see the resulting feedback from the users.
Sub-Hypotheses
In this sub-section, the hypothesis statements will be broken down further to determine the features that would be most useful to the app, as well as test the hypothesis statements from above. This will be completed in a table format, by utilising the user base the features are being aimed at. In this case, the user base being targeted is the general user (mainstream user). By targeting the biggest pool of users, we can make sure that the app is designed to a standard that is easy for ever user category as well as appealing to themOutcomes
Based on the hypothesis statements, the following outcomes are achievable.
– By providing the users with an app where they can provide useful feedback to developers of the game, we will deliver new features based on this feedback. Therefore, making the user happier, whilst also giving them a say in the development process.
– By making sure the developers engage with users, we can prevent the disconnect that currently exists between them.
– By providing users with directed feedback opportunities (through polls, questionnaires and discussions) we will make sure the feedback received from them will be useful.
– By designing the app in a way that is based on ease of use rather than the amount of features included, we will keep users’ attention on giving the relevant feedback.
Personas
This section covers some of the personas which represent the user base of Hello Games and their game, ‘No Man’s Sky’. These proto-personas help with identifying the target audience of the app being developed. By identifying the potential user base, and the reason the app would be useful to them, the process of designing can be adjusted accordingly. Along with aiding the design process, it will also help with feature selection for the application. The users in these proto-personas are based within the ‘mainstream user’ category. As mentioned before, this is so that the majority of users are considered rather than a specific group of users.
The users of the game are spread out on two gaming platforms, PlayStation 4 and PC.
Features
From the sub-hypotheses table, it can be determined what needs to be done in order to achieve a successful app. In this section, features will be considered to fulfil the needs of most users of the app. The following features have been decided, with justifications as to why they are required.
Feature
Justification
Voting for features
To give users a unique chance to select the upcoming features for the game.
Provide bug reports
To give detailed, contextualised information about specific bugs within the game.
Technical Support/FAQ
To give users a go-to page for troubleshooting and provide them with a place where they can ask any questions they want about the game.
Questionnaires
An occasional feature. Can be constructed to gather specific information about certain aspects of the game.
The main objective of this application will be to provide feedback to the developers for them to act upon, in order to fix their relationship with their users. The list above are some of the fundamental features that can aid this process. They will be broken down and described in detail, along with the implementation requirements for each one. All features will need to implement a database within the app infrastructure.
Feature voting – This will be one of the unique selling points about the app. It will be provided in the form of a live poll. The live poll will include a list of features, pre determined by the developers, where users will be able to vote on whichever feature they want to see next. The developers can then go on to implement each feature in order until the next list of features are published. This section will be periodic, depending on the speed of development, the developers can then use another poll to decide what features should be implemented in the future.
Providing bug reports – The bug reports page will be an area where users can submit the bugs they have ran into within the game. The page will have input fields where the user will be able to contextualise the event where the bug occurred, along with other inputs corresponding to relevant questions. These questions will be there to help developers solve the issue.
Technical Support Page/Frequently Asked Questions – within this section of the app, the users will be able to ask any questions that are relevant to the game. It will provide them with a basis of communication along with a link to the FAQ page, where they can search for their issue as well as see how to solve it.
Questionnaires – The questionnaires will be similar to the feature voting section. In the way that they will occur periodically rather than be a constant page throughout the app. It will be used as a quick feedback tool on the features that have just been released, or as a feedback tool on the app itself and so on. Depending on when there is a need for one, the questions can be changed and still provide useful information.
Technical Requirements
In this section, the requirements for the development of the app will be considered. The contents of this section may be subject to change depending on the new information gathered after the proposal and during the development of the app. When an app is made, the process of navigating through screens is a lot smoother, as well as the data already being loaded into the app file. With web apps and similar websites, the navigation usually depends on the connection speed of the user. Although a web app would be more convenient to build and maintain, it would create a user experience that is not as seamless as an application could provide.
Due to the nature of the app, there is very little need for the use of device hardware. The app has not got any features that require extensive processing power, and does not require access to use most of the hardware that current generation smartphones have. However, there is the potential to use some of this, If needed in the future. The camera capabilities of the phone could be used in a way to make sure that the users own a copy of the game, to reduce the amount of people who do not own the game using the app. They could scan a barcode that could be generated in-game upon login, which could also be used as a login method.
Operating System: Android or iOS?
One of the hardest things to determine throughout the planning process for an app can be deciding what platforms to support. Depending on the context of what is being developed, the decision will always be different. The main decider, in this case, is the amount of users that will be exposed to the application as a result of the choice made. When choosing the platform to develop, it is important to consider what device the user has, other than the one they use to play the game.
Due to the purpose of the app, which is to provide users with a better overall experience whilst playing the game, the profit that could be made is not considered in this case. The app is not being created for the purpose of making a profit, it will be provided free of charge on the respective app store. Which is the reason for revenue not being a decisive factor when deciding between which platform to develop on.
The current worldwide demographics of android and iOS users depends on what context is being considered. A majority of android users in the world live in areas with low income or in a developing country. In contrast to this, most of iOS users are from developed, mostly educated and wealthy areas (Evans, 2014). In the case of the ‘No Man’s Sky’ user base, there is no data as to which devices the users are using. However, the user base is mostly gamers who have some experience in tech, and can afford to buy a gaming console/PC to play the game, they will most likely have either an iOS or an android as their mobile device.
This leaves the question of which platform to choose. By having an application developed for both, it would provide the game with almost complete market exposure. Which is what one of the main concerns of the application are, to be exposed to as many ‘No Man’s Sky’ players as possible. The ideal scenario would be to develop apps for both platforms at the same time, and release them at the same time. But, due to the size of the team at Hello Games, this would be extremely hard to maintain without devoting a number of employees for the job.
Preferably, in an app development environment, development should begin on iOS. Solely for the reason that the users of iOS adopt apps much quicker than android users, as well as the higher rates of adoption when it comes to new operating systems. Only 1.2% of users run the latest version of android, which makes the development process a lot longer (Hill, 2016). It makes it longer in terms of the number of previous versions that need to be supported, as well as the variety of android device drivers that need to be included within the app, which makes it bulky and very tedious to develop. Whereas with iOS, there is only one manufacturer of the devices that use it, and the adoption rate of adoption for the latest operating software is a lot higher than that of android.
Where both platforms can be developed for, the number of users the app gets exposed to naturally rises. This is what the application in development needs the most from the platform it is developed on, exposure to the games user base. Which is what makes cross-platform support the most suitable choice for Hello Games’ app.
For the purpose of this development project, the application will be developed on Android due to the open source nature of their development process. It will support android builds up to android 4, which makes up around 76% of the android market. (Hill, 2016)
Feature Requirements
The features included within the app have been kept to a minimum to ensure the app remains a simple, usable app. These need very few resources other than the application being distributed. One of the main back-end requirements are databases for most features. They will need to be on a server, and only allow access to developers. This server will be provided by the company, but modified by the developers of the app. The transfer of data between app and server will be done over the internet, which means that the app will need to have access to the internet connection that the phone is using. Other than a database, the app will need a form, for questionnaires and the development of the separate pages for each feature.
The way in which the users will be able to sign in to the app, and how the developers will know that the users actually have the game, is through their respective gaming providers. (PlayStation Network or Steam.) To have access to the login functions of these services, API’s are required to access the data from the source to be able to validate login credentials. This is the only service required from 3rd parties.
An initial feature idea was the addition of threads. By providing the means for users to interact with one another, as well as the involvement of the developers, threads could be an area where the user base of ‘No Man’s Sky’ comes together, rather than having a place on third party websites and forums. The interaction between users and sharing individual experiences about the game would make the application the complete hub for all users of the game, if cross-platform can be achieved.
However, due to the existing threads and forums, there is currently little demand for this feature. Once the rise in user numbers have been established, as well as user numbers within the app, then it might be a good idea to implement the feature. Another way of knowing whether the user would want such a feature is with the use of a ghost page. Having a button that leads to where the threads page would potentially be, with a short description of what the page would hold, if created. This button could work as a counter, to see how much demand this feature has based on overall user numbers. (Gothelf and Seiden, 2013)
Design Elements
The design of the user interface is crucial to how the user navigates within the app, as well as making the app amazing or just confusing. The main concern with designing an interface, is trying to understand the user and their behaviour within the app. By designing a good interface, you can improve the user experience as well as make the app more comprehensive and natural (Galitz, 2007).
Navigation is also an important part of UI design, the way in which the user navigates throughout the app determines how well the app flows. The best form of navigation is to have none at all (Tidwell, 2011). Here, Tidwell means having everything in one place, if possible. This decreases the chance of users being lost within the many pages of an interface, or having to go back and forth between pages constantly. However, this does not work when the app has multiple features where a page needs to be dedicated to each one.
In this case, Tidwell offers several concepts of navigation throughout a given interface. The one considered for the app is Global navigation. Along with having a landing page where all options of what the user can do are presented to them, providing a form of navigation that does not require them to go back to the landing page. Instead, the user will simply use gestures to swipe through from screen to screen. This will be presented to each user when they first enter a given page. A pop-up window will be used as a ‘tutorial’ on how to use the mode of navigation.
Minimum Viable Product (MVP)
The process of creating a MVP is part of what makes the Lean UX methodology work so well. By creating paper based prototypes before programming the actual application, it can reduce the time it takes to make changes to it. This is also a good way to visualise the design of the app, to see if the layout of certain pages would work well with what they are being used for. Below are scans from the paper prototype created. The way the app flows will be demonstrated with a few examples of completing a given task. Image 1.1 in the appendix is the scans of all the prototype screens designed on paper. Within this image, you can find the features and screens that need to be included in the final product. These are the core features of the app, and need to be perfected before any other extra features are added.
The initial designs for each screen can also be found within the appendix as image 1.2. This shows how the rough layouts of each screen before their final forms that are shown in the images to follow. Below, are two examples of how the user would navigate within the app. The pointer shows the location of the users touches on the screen and the arrows represent the progression onto a new page. Once on a certain page, the user can swipe to go onto the next page, or press the logo or back icons to go back to the main menu.
Image A
As shown in image A, the screens menu screen uses icons and labels to make sure the interface is clear for the user. Each page has a short description of what their functionality is as well as always showing the user where they are, through the use of the label in the top left hand corner of the screen.
Image B
The contents of each screen has been designed in a way to be consistent throughout the app. Having a consistent layout makes it a lot easier for the user to get the hang of navigating around the app.