Discovery, what's the big idea?

12th June, 2020

Published by Hamish Kerry

The fabled question most software developers that use a discovery centred approach to projects will have heard a multitude of times, “What is the point of discovery?” “What does discovery mean?”, “What does it achieve?”.

At Arch, we sit discovery at the forefront of our projects. It’s validity as a practice is widely acknowledged by the team as being essential to the success of the project. But what actually is discovery? And why is it important?

We’ve created this blog with the hopes of educating what we achieve along the way.

Setting up the concept

We believe that a proper description of the idea should fit in one sentence. The sentence may include a core feature of the application so that the reader understands instantly what the app is about. For example, if you were looking to develop a calorie-tracking mobile app, it could be, “An app to track calorie consumption to help those who care about their weight.” This is an excellent first step to ascertaining what the client desires as the core function of the product.

Identify the sequence

“Humans are pattern-seeking story-telling animals, and we are quite adept at telling stories about patterns, whether they exist or not.” - Michael Shermer.

Navigation patterns aren’t just evident on the open ocean, they form an essential framework on which we’re able to develop software. Discovery allows us time to assess these patterns in your competitors or applications of a similar strain. From this analysis, we’re able to promote a navigational pattern on which a user journey is plotted.

Intensive identification of navigational sequences ensures we’re not leaving out core functionality otherwise available in competing products.

"Form (ever) follows function"

Famous modernist Architect, and ‘Father of Skyscrapers’, Louis Sullivan once said, “...form ever follows function, and this is the law.”. If even slightly poetically, the substance of Sullivan’s words ring more true today than when they were first put to paper in 1896. With a myriad of options for styling, colours, and layouts, it can be hard to ascertain the right direction for your product.

Discovery cuts out the conjecture that often arises when conceiving initial designs but placing a focus on the function of the product, rather than the form. The majority of users have little interest in the colour scheme, however, they do attach a large amount of interest to the question of whether it will solve their problem.

Prioritisation

Convey which features are more important than others, so that the developer knows what to focus on first. We usually follow the MoSCoW method, marking items with “Must,” “Should,” “Could” and “Won’t” levels of priority.

The MoSCoW method can help us ascertain the essential functionality of the product, and allows us to develop a flexible pricing and timeline structure for overall delivery.

M - Must have this requirement to meet the business needs

S - Should have this requirement if possible, but project success does not rely on it

C - Could have this requirement if it does not affect anything else on the project

W - Would like to have this requirement later, but delivery won't be this time

Develop User Stories

A user story is less formal than an FSD (functional specification document) yet still very powerful. It lists the things that the user can do in the application and is described from the user’s perspective. The document could also briefly explain why the user would want to do it if that isn’t apparent of first reading through the brief.

Let’s take a calculator example and add a few other features, describing them in a user story format:

As a user, I want to be able to change the number notation from decimal to exponential (and vice versa), so that I can work with very small or very large numbers.

As a user, I want to be able to export a calculation’s history as a PDF file to share with my colleagues.

Because of the explanation, such a format provides not only a technical overview of the requirements but also a good business case for them. Thus, if a feature is identified that is not critical to the business, you could decide either to completely remove it from the scope or to postpone it to a future release.

Using this format, you can easily split one story into multiple sub-stories to provide more detail. For example, we could split the PDF-exporting story into the following sub-stories:

As a user, I want to be able to tap on the sharing button (top right of the screen) to see my options (sharing as PDF, text, image). Once I select a sharing option, I want to select the calculation timeframe that will be shared, using iOS’ date picker.

Because of the simplicity and non-technical nature of user stories, it can make it easier for you and your team to understand the specification for the product you’re setting out to build. It can be a catalyst for conversations around changes, prioritisation of features, and potential design language you want to employ.

To conclude

Discovery is an essential part of the development process. It’s the catalyst for the client/developer relationship and the former of guidelines by which all parties will follow. While we haven’t included an exhaustive list of all of the elements to discovery, we hope you’ve gained some insight that will allow you to further appreciate the essential nature of the discovery process.

Witten by Hamish Kerry, Marketing Executive at Arch

We'd love to chat about your project!

We're here to help. If you've got an idea or a direct need you would like help addressing, we're all ears!