The first part of an inside look at how we work — from the initial meeting to development.

I will try to describe the process we go through with each of our clients. Obviously, some specific parts vary from case to case, but the skeleton remains similar.

It’s important to have some kind of process defined. It helps you remain focused on the client, avoid chaos, meet the expectations and deliver on time.

Disclaimer: This is by no means a definitive guide or an attempt to nail the best practices. I always enjoy reading about other people’s process. It enables learning on both sides: readers get an inspiration and insights, writers can get useful suggestions on the topic.

Outline

The initial meeting Wireframing & rough prototype Refining wireframes & definitive specification High fidelity design High fidelity prototypes Communication with developers

Note: I quickly realised that fitting all this into a single article would be too much. To avoid that I decided to break it into two parts. You are currently reading the first one. Make sure to follow us to get notified about the second one and many other articles about various topics after that.

1. The initial meeting

We don’t have any photos from that, so hmm… Imagine a nice, airy conference room. Glass, wood, bare concrete. Epic view on the city from big windows spanning from the floor to the ceiling. Got it? Let’s move on.

Understanding the business

It doesn’t matter if it’s going to be an app or a website. It also doesn’t matter if we are talking to a startup or an established corporation. We always want to understand the client’s business. That means asking a lot of sometimes tough questions like:

Who are your customers?

What problem do you solve for them?

Do they have a viable alternative to you?

How do they usually find out about you?

This list could go on, but mostly it picks up a direction based on the first two answers. Why do we ask these when all you want is just an app?

Because if we don’t have this information we can easily end up with something nobody will want to use. If we don’t understand your customers we can’t possibly tailor an app for them.

This also means learning a thing or two about the actual business the client is doing. Is it going to be an app for golf players? Learn some golf talk. Is it going to be an app to communicate with local government? Good luck with that. (We actually did both of those. Case studies coming!)

Identifying problems

Second thing we discuss in the beginning is the actual problems we are going to solve. The client might have an idea, but usually it’s something like this:

“I have a successful website that provides complete client management for golf coaches and enables players to manage their lessons and communicate with their coaches. I need an app to do all that on the go.”

Let’s look at two possible scenarios:

We collectively nod our heads, shake hands and get to work mirroring the website.

Results may contain: Huge budget, distant deadline, uncertain adoption from customers. We dig deeper, learn about the essential needs of golf players on the go, how their coaches interact with them on the website, in what cases they need to use other services and so on.

Based on this information we form an MVP, containing only the most important features and continue from there.

Results: Smaller initial budget, close deadline, good adoption from customers.

I’ll let you be the judge of which scenario is the right way to go.

We always try to go the minimal, “startup” way regardless of whether we work with an actual startup or not. It’s incredibly hard to guess people’s needs, so why not just hear them out and act accordingly?

Asking a LOT of questions

This is the time when we may be a little annoying. And we’re not sorry. What gets forgotten or ignored in this phase is going to be harder (= more expensive) to fix later.

Defining scope

To wrap the meeting, we usually sum up all the key findings and define what we will be working on. Main part of this is often done outside the meeting room. We prepare a clean structured document outlining all the features planned for the first release together with project time and cost estimates. Let’s call it The Document.

Tools used: pen, notepad, text editor (nothing fancy at this phase)

2. Wireframing & rough prototype

Time to get our hands dirty. We start offline — usually with pen & paper or on a whiteboard always keeping one eye on The Document.