Problem

Joining and working with startups is always a rollercoaster. Of duties, of relationships, of emotions… However getting to build potential services that are not there yet, or enter markets ripe for innovation, is an equally exciting and nerve-wracking experience. From one hand, the team has the chance to disrupt a market (potentially!), and on the other hand, no data at hand to work with. The latter realisation serves as part of the problem in designing a mobile app and crafting the UX process from scratch.

Audience

In an emergent market we had an idea of the audience. However those were guesses based on studies, market research, own wishes and needs, and friends & family. In truth we really did not know how people will react to the service we are building. An app, especially a marketplace, has broad customers and their needs tend to also be broad. There are power users, tech-savvy users, and also people who want to achieve something through the app but have not used many apps like this. Or even any!

Designing an application that can serve a variety of customers with a variety of skills and motivations can be tricky, but getting to know the users and their needs can help tremendously. Getting out there, trying to find potential test subjects to prove the hypotheses you formulate should be done really early, if possible. Even testing within the team, is better than nothing.

Process

User stories

Before getting to design anything we wanted to get an overall understanding of our users. Those are standards we based the whole process on, but ideally they served as the platform, to gain insight on what people might expect from the app. Then we would test those hypotheses with real users. Now, these processes can cost, or they can also be a free resource if done smartly. For my team for example, in Helsinki, it only took a visit to Startup Sauna — a business incubator in Otaniemi, and we could find dozens of people to provide feedback on our designs.

The user stories, did not have to be exhausting in detail but they should give a pretty well drawn picture of the desired/potential customer.

Key characteristics: These are the needs and wants
The story: The main story that serves as an example of why user X is using the app at the moment
Goals: The achieved/desired results of the user
Frustrations: The Problem; what user X wants our app to solve for her

These elements can serve as the initial step to becoming more acquainted with a few variants of users and later used to create scenarios.

User scenarios

After the stories, we already had an understanding of what the users want. So we dwelled into the structure of the app. In the scenario phase, we did not have to know the whole process of the app but we wanted to include multidisciplinary skills into the mix. Engineers to map down the development processes, business developers that have the scope of the whole concept and of course designers who can visualise and draw the flow of user steps. This way the whole process of scenario creation would not be vain but rather a joint exercise that gives the whole team valuable learning and everyone sees the first goals being drawn out.

Mapping the Journey

After scenarios (the more the merrier!), we “zoomed out” to observe the whole picture. Scenario A had a different purpose than C and was a bit more similar to D, but F is most important along with B. Scenario E showed a bottleneck in the design and we had to see a solution to that. This is where we actually started mapping the user journey of the app.

There were many targets here:

How to navigate to the most important screens?
-We chose bottom bar navigation
How easy is it to go from login to the end of an actionable result (purchase or whatever)
-We chose a natural flow that followed the login of the bottom bar
Which is the single most important part of the app?
-so making THAT dead simple.

Design

The design phase is usually something that takes time on its own. Design was planned in sprints. In startups it is typically a process that happens in parallel with business development as well. The reason why this is also a good thing is that we would likely come up with many different solutions and challenges, and once we have had a process drawn we had to realise that we could not keep all the features we wanted. Being critical on what is needed vs what is nice to have, can help save time and resources. Of course having a backlog is also helpful, so organising with an MVP in mind is what created a truly agile and iterative process.

Retrospectively the design process should start with initial wireframes (good ol’ pen and paper), and then gradually moving on, creating lo-fi elements to hi-fi elements in time. We did not focus on creating pixel perfect designs as this can prove to be irrelevant.

Internal testing

Testing with a design can be easy and we did not need initially any investment in this step. Simply uploading and linking the screens in InvisionApp created a mockup that could communicate the service as it would be as if it was running like a real app. We could even test 1 or 2 different paths of the customer journey with an analytical, and critical eye on the designs. The best question to ask when conducting those tests is not the HOW does this user is using the app but WHY. Why he cannot go from point A to point B easily? Is there something not clear? What can be done differently? Understanding those questions can tackle many challenges in the whole interaction of the app.

Feedback

Time to fix, iterate and continue. This step had to be done with real users. Again, the same principles applied. Why does person X like the app? Is she tech savvy? If not, is it too challenging to use the app? Is the message clear enough? Does the user feel she can trust this app can help him take care of her need? Answering those question helped set the metrics for the app and its potential success later on, and saved significant time especially in this stage without having started the development.

Development & design iterations

In this stage our understanding of the app had to be exceptional. Tests validated or disproved many initial hypotheses, we iterated on the designs, made sure we have crafted an easy to use process, making ground for the development to start. This step can give time to work on further iterations, fix or redesign screens and start to create a more detailed design, with correct patterns and sizes. Testing on different devices, both in design screens but also prototype, was a good call, as we found out what works best and try to find a middle ground for all the elements.

Result

By the end of this process we had a full scale application similar to commercial and already running apps. The scope of this whole process with minimal resources was around 4 months with part time commitment in this project.

Key findings

Creating a process from scratch is a long process, however it holds many gains, learnings, and of course mistakes. Miscalculating time seemed to be a primary problem.
Being ambitious with what we wanted to map down in our app was a bold move but certainly a huge investment into the future of a market that is yet extremely ripe.
Limitations were present at all times, because not all solutions can be technological. We had to keep in mind that over all, we had to still work with traditional systems (payments etc) for many parts of the app.
Kill features, and move on. Yes, the worst fear of every designer and developer. Killing your darlings. If we would have implemented all the ideas we had our whole process but also the end product would have failed. Finding what is right for an MVP, then a pilot and then a full-blown app, and having a backlog can serve as a great tool. Understanding what is important for the users can also help you let go… of many ideas, features and even implemented solution you might have had.
In our designs, I always chose the atomic model so even if something would get thrown out of the app, there are still elements from that part to be used somewhere else.