Zoe's Blog

Foreword

In this article I refer to just myself and a client because I am assuming the roll of a freelancer taking on the full responsibilities of setting up a new web app. The requirements gathering process all still applies to team based projects, though. So if this is the type of environment you work in, just replace any time I mention client with Product Manager. In either case, it is simply the main person that understands the problem domain the best and is taking responsibility for helping you learn what you need to know in order to get the design and development under way.

For our given case study, we are at the very first stage of design: gather requirements! In this fictitious scenario, we have just agreed to work on this project and so, need to get to know the requirements a bit more.

All the information that we gather can be put into two lists: functional and non-functional. A functional requirement is a particular behaviour that must be achieved by the solution we design and implement, whereas a non-functional requirement is any criteria that the solution must meet. We'll get into examples of these and how I like to document them later.

The discussion we have with the client will concern itself with functionality only as, styling will be covered in future posts.

What is the problem that the platform is going to solve?

The most important question to ask first is "what is the problem we're trying to solve?" The client and myself would need to agree on this opening statement first.

The problem description for the ReaderWriter platform is this: it is currently hard to connect with other people interested in or in the publishing industry, whether you are a book enthusiast looking for your next read, a budding writer, or a top author wanting to stay in contact with your fanbase. Everything has it's own platform or way of making contact. This can be summarised as three problems, for three different kind of users:

Problem 1: book reviews are is often tied to a company that sells books, so you cannot easily see all reviews for this book in one place.
Problem 2: new writers often find it hard to get exposure to the publishing industry. Even if they can put of examples of their work, it is often difficult to get professionals to review it and give improvements. Indeed, many still go through long and laborious manual processes to get their work sent to different publishing houses.
Problem 3: established writers normally have to set up their own website in order to let fans know about their past and upcoming books. With social media becoming so prominent, it would be easier to have a platform that they could show off all their work and stay in touch with fans.

The inventors of ReaderWriter believe that these problems could be solved in the same place. They envision this platform doing many things. With it, book enthusiasts can stay up to date with their current favourite authors, as well as potentially discover new ones. New writers could be discovered by these users, as well as users within official publishing houses, who could provide feedback easily. Established authors could drum up excitement for their new books, as well as connect with other authors and professionals in the publishing business to kickstart new projects.

I know what you're thinking-- that's sounds like quite a lot of work! Not to worry, that's the problem that the platform as a whole is trying to solve, which is the story that will be pitched to potential investors. The problem that we will be tackling here is smaller, and that is to prove that it can get there by solving a few of the problems outlined above.

Why am I bothering to set up the story for this platform? It's important to always have the overall objective of the company in mind, as well as where they are on the roadmap to achieving that. It will help give context as to why certain functionalities are prioritised first-- something that is really important!

The current problem

So that's what we need to confirm next with the client-- what do you see as the first problem to tackle here? Well, since it's going to be a social platform, it's quite important to get some users on board. Therefore, I think a good place to start is solving problem one. The people who are wanting their next book will make up the vast majority of the users, and they will be important as the other two problems could be solved with the help of some of these users' actions.

The client agrees, with the stipulation that the designs are still drawn up for a basic author page, as it can be used in the meeting with possible stakeholders to show the platform intends to be more than just for reviews. So we're aiming to solve problem one and a very simple solution for problem three.

Breaking down the problem

Now that we feel the problem is more clearly defined, we need to start start breaking it down into more manageable chunks. I like to do this with user stories, which is common in Agile software development for capturing requirements. For those that have not come across this before, it follows the template:

As a [user role] I must/ should/ would like [feature] so that [reason].

And it has worked well for me because of these reasons:

Defining user roles that are concerned with pieces of functionality makes you aware of these roles. The earlier you can start conceptualising what permissions and abilities each of your user types have, the better.
Describing the feature over the solution encourages experimentation with the best user flow. Rather than saying 'I want to be able to use a dropdown to filter book category', it's better to say 'I must be able to view books by category'. The second phrase clearly describes the behaviour, but does not say how this is achieved. It is in the next step (low fidelity wireframes) to explore the best way in which to accomplish this. That way, the feel of this interaction can be tested, rather than one solution being assumed to be the best.
Giving the motivation for the user to have this feature makes it clear why this feature is or is not important. This is really useful for prioritising work. These user stories should be agreed upon by everyone in a team so that it is always clear why a particular feature is being developed.
Using must, should and would like indicates the priority of the functionality. I don't think everyone does this, but I find it useful. It's something that you can easily talk to non-technical people about (which often clients can be) and allows you to, you guessed it, manage those expectations. As long as they know those special words indicate priority, when they agree to the functionality list, they are therefore agreeing with said priorities.

The Result

The discussion with the client goes really well. We come away from it with a list of agreed upon functional requirements:

As a general user, I must be able to see others opinions on a book so that I can see if others enjoyed reading it.
As a general user, I must be able to find a particular book so that I can decide if I want to read it.
As a general user, I would like to be able to find new books so that I don't run out of new ones to read.
As an author, I must be able to tell people about my upcoming book so that my fans know to buy it.
As an author, I must be able to tell people about my previous works so that they can buy what I have already released.
As an author, I should be able to interact with fans so that I can build up my fan base.

And here are our non-functional requirements:

As a general user, I must be able to use the app on my mobile/ ipad or computer so that I can use it wherever I am.
As a general user, I must be able to use load any page in the app in under 4s so that I can navigate easily.

Conclusion

You may think this was a really long winded way to get to the list of functionalities, but I'd say it's definitely worth the time. These kinds of conversations will keep them aware of what will be worked on and is a great way to help manage expectations. By keeping them involved, it also acts as an agreed upon checklist that can be used to measure the design/ implementation. In the next post I'll be going over how I'd start getting in the mindset of our intended users, and how that can then lead to some low-fidelity designs.