Mobile App Development Process at Rosberry. Discovery and Inception Stage
By Sacha Lopatyuk, Art Director at Rosberry
In the IT business, companies build their internal processes over years, going the same road again, writing guidelines and rules the hard way. There is no one-size-fits-all process which would be accepted by the community to the dot, so from time to time people like to look ‘over the fence’ to see how everything works there. Until you look over, you think that dollars are greener on the other side.
We don’t know how useful our experience could be for anyone of you, but from now on we’ve decided to gradually increase the transparency of the development process at Rosberry. We believe it might make the life of our clients easier whereas peers could compare experiences.
Sure thing, we haven’t come to the current understanding of the development process with one flick of a magic wand. We still have to deal with lots of issues — we change, modify and improve almost on a daily basis. No doubt, we read and keep on reading smart books, we study third-party experience, but everything that is used now has been tested by us as a matter of practice and hard won.
The whole process at Rosberry, probably like in many other studios, consists of several stages. So far we have eight:
1. Discovery & Inception
2. Wireframing
3. Visual Design
4. Documenting
5. Development
6. Testing
7. Launch
8. Support
In this article I will talk about the very first stage — Discovery & Inception (D&I).
This stage takes 2 to 4 working weeks on average (depending on the project scale and complexity) calculated as 1 UI/UX analyst designer to spend 40 man-hours a week. We have to be honest, at the pre-project stage almost every client says that it is an additional money-consuming piece which they believe we can do without. And yes, we spend a lot of time carefully explaining what it’s all about and why it is so important. But all these efforts are absolutely worth it. For the last 10 years, we have learnt that in 98% of cases, even a well-established and full-fledged business reaching out to us with a specific task, in a request for proposal can hardly cover all the points and answer all the questions we would need to develop a high-quality product (both in terms of design and development).
At the pre-project stage both the client and contractor often understand the importance and priority of information differently. Preparing a project description, the client, as a rule, looks past the things which become really pivotal at the wireframing and visual design stages. But no big deal. Actually, we are all here (running through brick walls) to help a client deal with any issue and bring something useful, beautiful, user-friendly and cost-effective to life.
By the way, no client has ever told us that we wasted their money at the discovery and inception stage. And conversely, each of them started looking at themselves, their idea, the whole project and, of course, at Rosberry quite differently. By ‘differently’ I mean in a more objective, more organised, more cost-effective and market-conscious way.
And now, let’s give a closer look to the D&I stage.
Discovery and Inception in brief
At this stage, we define and describe the target audience, write the app use case scenarios, develop a Customer Journey Map from the moment a user learns about the application and to achieving their goals. Basically, we do our best to understand and describe what we will do and for whom — the more details the better.
Doing the job at D&I stage, we often come across quite a large, if not to say, a huge number of interesting business, organisational and technical tasks, as well as functional features of the application, which our customers have neither suspected nor thought about. Thanks to the collaborative work at this stage, the designer, the product owner and the client understand what they will get in the end. They understand it in every way: functional, time- and cost-wise.
1. Business & subject domain study
This stage is an introductory, yet a very important step allowing us to understand how the application will fit into the client’s business and help to potentially develop it further.
Sure thing, depending on the specific character of the client’s business, we first prepare a list of questions to be asked. Then we arrange a conference-call and discuss everything in detail. After this long conversation (oftentimes several calls) we make a document which comprises everything that we have managed to find out and learn. To make it easier for the client to communicate, we often provide a list of questions in advance. Yet again all the details are discussed only during voice-calls because lots of additional questions may come to light throughout the dialogue.
Actually, the more honest and open a customer is answering our questions and sharing information, the better we understand their business, their goals, vision and challenges we would help them with.
2. Personas
This stage consists of several parts. First off, we set up a call with the client to discuss the target audience of the app. We keep on asking many questions to find out how the client sees and understands prospective users. Of course, we do not stop here, because without our own analysis, this understanding of the audience will be one-sided and pretty subjective. When it comes to a lifestyle app (there are lots of them in our portfolio), we often interview users, study their open profiles, tastes, expectations, suggestions and feedback shared, etc. If the client already has an app or a website running, we study the analytics of those products.
Based on the analysis of the data obtained, we flesh out several generalised characters: representatives of the target audience whom we will make the application for. For these personas we describe their pains, needs, desires and so on. To do this we use our universal template with a description of all the characteristics we are interested in. We often get back to these personas at the design and development stages to make sure we are not shying away from the needs of these people.
The result of this stage is a document describing these very personas: fictional personalities with a set of characteristics peculiar to our target audience.
3. Competitive analysis
At this stage, our task is to understand whether the client’s business or its prospective mobile application have any competitors. How the competitors’ apps work, what solutions they have implemented, what reviews their users share — all this is the invaluable knowledge that has to be taken into account when developing a new app.
Everything is analysed, studied and described by us and the result turns out to be a table with the information collected and processed. We look for ways to use the best practices found within our project and learn from the mistakes of others.
Almost all our projects are implemented to solve a specific business problem of the client and meet specific users’ needs. To help the client grow and start solving even more clients’ problems through offering them something completely new, we need to know the market, i.e. the current situation. Competitive analysis just shows what clients’ needs and expectations the competitors have already met or are trying to meet.
Sometimes the task becomes a complicated one, as there are no direct competitors or they are not so obvious. In such cases, you need to understand how users are currently trying to cater to the needs our application will respond to. It is important to identify patterns, pros and cons of the solutions.
4. User stories
Based on the data collected so far, we will write the main user stories of how our personas are going to interact with each part of the application. The result of this work will be the document describing in large strokes the main needs and actions of the user from the point of view of application. These same stories will form the backbone of the wireframes, documentation and the Behaviour-Driven Development scenarios (we will talk about them in the articles to follow).
A sample user story might be the following:
In order to find a photographer for specific needs (say, for a wedding),
Samantha wants to use the search option to find a photographer she needs and filter the results based on various parameters.
5. Customer Journey map [CJM]
CJM is the stage at which we describe the entire path of the user — from being unaware that the app exists and up to meeting their specific needs through the application. The result is again the table covering many nuances, potential issues and pitfalls revealed, which are very difficult to notice without tracing this entire path:
1. A desired action at each stage and a success criterion.
2. A point of contact with the business at each stage.
3. Actions taken by the user at each stage.
4. Potential barriers and issues that may prevent transition from one stage to another.
5. Ideas to solve the issues faced.
More often than not at this stage that we reveal the problems no one has ever thought about. Customer Journey Map helps both us and the client to see the entire user flow and come to a common understanding of it.
6. User Flows
In parallel with CJM, we are starting to make flowcharts detailing the user flows within the application according to the scenarios we have described before and based on the issues additionally identified at the CJM stage. These charts help us to create the most convenient navigation throughout the application and to make provisions for all the uncommon interface states.
7. Information architecture
Information architecture is a mind map that organises the architecture of all the elements, screens and information within the application.
At this stage we also try to highlight what the user might really need in Version 1 and single out the feature-sets to be a part of the app versions to follow. By doing so the client can immediately see how the app will evolve in terms of further enhancements and development (a roadmap), and we can have a preliminary plan of further cooperation.
8. System architecture
A system architecture is a diagram that shows the relationship of all the services and parts of the system making up the application. For example, backend, mobile application, web version, payment gateways, admin panels, cash registers and so on.
It actually is an optional stage, but very important when we build complex systems consisting of more elements than just the backend and the mobile application. It allows us to clearly understand all the relationships and interdependencies that we have to build. Moreover it allows to get rid of a lot of confusion and bugs at the development stage.
Conclusion
You might ask: ‘What the heck have you told all this for?’ I guess, just to once again remind ourselves and others that one should not rush to start the design stage (both wireframing and a visual part) without immersing into the project details, the business domain itself, expectations and vision of the client. 180 projects we’ve implemented so far suggest that a structured approach to the Discovery and Inception stage as well as additional 80–150 man-hours spent at the very start should be considered a strategic investment not only into the quality of the final product, but also into balanced relationships and healthy communication with the client. The Discovery and Inception stage removes a lot of questions that often force developers to revise their estimates on the go, which is not easily understood and accepted by clients.
