This blog post is the second in a series, describing how app development works in a typical client-agency arrangement. The intended reader for these posts is someone who is looking to get an app made, who wants to know how the process works. This series covers how you might work with an agency to build an app, and incorporates some of our learnings from our previous projects on what tends to work best.
The requirements gathering (aka requirements elicitation) phase is incredibly important to building an app that is useful for the eventual users. Requirements gathering includes exploring user personas and key stakeholders, conducting user research, and figuring out what the fundamental requirements of a project are.
Requirements not Solutions
The most important idea to keep in mind for successful requirements gathering is that the process should be followed without being swayed by your preconceived notions of what a solution might look like. The goal is NOT to work out whether a solution you have in mind would work for your potential users (that comes later), it's to figure out the fundamental requirements of the distinct stakeholders.
Identifying the fundamental requirements is very important as it can often highlight opportunities to handle an entire process in a better way. One trap a lot of apps fall into is trying to make an existing manual process digital, and in the process simply recreating an existing inefficient process in app form. Think about if banking apps simply allowed you to write out a cheque on your phone screen – this would have still offered a lot of benefits over carrying around a physical chequebook, but completely misses the fact that a password-protected app doesn't need to send a cheque to the banks, it just needs to authorise a payment, and there are more efficient ways to do that than cheques.
The app development agency you’re working with should be doing their best to cut to the core requirements you have so that they can work with you to develop creative solutions. The end result may end up looking a lot like your original concept, but working through the process is important so that you know you’ve arrived at the optimal solution.
Who are your Stakeholders?
Requirements gathering needs to keep in mind the needs of all the stakeholders involved in the business viability of the app. The term stakeholders covers a wide range of people – not just the users of the app. Stakeholders include everyone who will be affected by the success, failure, or the particular features of the app. Examples include investors, users, people who will be making use of the data collected by the app, advertisers, and people affected by the changes in process resulting from the app.
Stakeholder requirements are vital for prioritising features and designing a successful app. For example, depending on the funding situation of an app project, it might be vital that the app makes money as a Minimal Viable Product (MVP); at the other end of the spectrum, user acquisition might be the most important requirement, with revenue generation being something that can come after the MVP.
User Personas
Successfully identifying the different kinds of users who will use your app, and extracting the most important requirements from them, is a key part of this stage in the app development process. Knowing the limitations and expectations of your users is important to be able to create user experiences that are intuitive and enjoyable to use.
The typical method for understanding your types of users is to develop ‘personas’. Personas are fictional characters that have attributes representing a whole demographic of your potential users. These attributes are based on both known facts about your actual or planned users, as well as speculative factors that you think will be important. For example, if a subset of your users were young, white-collar professionals, you might develop a persona such as Jane, shown below:
These user personas can be as simple or as complex as you like, but the key goal is to have a name and a character to relate to; it’s much easier for you as an app designer to imagine whether Jane would like a feature than it is to relate it to an abstract concept like young white-collar professionals.
The next stage from identifying your user personas is to conduct user research. At one end of the user research spectrum is fact gathering, based on data and statistics, i.e., data about the average age of a user group, which could lead to one requirement being to support poor eyesight. Fact gathering might be done through your own data collection, such as surveys, or it might be making use of existing research that has been conducted. At the other end of the spectrum is gathering insights from a small group of example users. This usually takes the form of interviews or workshops, where a number of different questions and interview techniques are used to work out the specific needs and requirements of a kind of user. Interview data is potentially less applicable to all users, but it gives insights and the ability to develop empathy with users in the way that data doesn’t.
Design Sprint
Requirements gathering and developing the design and concepts of an app are often paired together, as part of a ‘Design Sprint’ - at Lab3 Apps we call this the Design and Scoping phase. When combined, the processes are often performed iteratively, with user research being revisited to validate the concepts that get developed. We’ll discuss this more in our next post, Ideation and Design.
