Design process inside Lunadio — I. The initial meeting, first wireframes and The Trap
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.
This part is really about exploration and idea generation. We start with basic flows using only text to describe actions. Based on these flows, we decide what goes where and what it should do and project that on paper. Screens that make the most sense are then transformed into quick prototypes, just to see if they still make sense.
Don’t settle for the grid of screens
Clicking through a prototype says much more about viability of the design than just a plain static grid of screens. You get to touch and feel how the app works just a few hours after the initial idea.
Creating the prototype may sound like too much work in the beginning, but with current tools it’s really simple. Last time we used Adobe Experience Design because you can draw screens, wire them together and export an online interactive prototype quickly and easily, without leaving the app.
This part is easy to write about, but it’s really important to make the most out of it in practice. You don’t do all this extra work to just show off in front of the client. Interactive demo enables you to test ideas in real world with very little consequences for failure. If something sucks, you fix it in a matter of minutes.
Adobe XD allows you to export the prototype on the web, giving you a link you can share with others (and the client) to view anywhere. It’s also dynamic, so if you make any changes you don’t need to update the link and send it again and again.
Tools used: pen, paper, Adobe Experience Design (or InVision Craft, or anything where you can quickly draw, connect and give life to screens)
3. Refining the wireframes & definitive specification
Imagine the same conference room we were at the initial meeting. We’re here because we need to refine the wireframes with the client. Taking suggestions for improvements is vital, but don’t fall into The Trap!
What is that, you ask? If you’re not careful, you can end up with a lot of your well thought out designs changed just because you wanted to please the client. A lot was already said on that topic, but just to be sure:
Don’t blindly agree on everything, but also don’t be a defensive ass dismissing any new idea protecting your precious designs.
There’s no shame in saying: “That’s an interesting idea, let me write it down and we’ll think about it more” and actually doing it.
Practicing this approach allows us to do the work the client hired us for: solving their problems. We can’t do it on the spot and jumping to hasty decisions can be costly in the long run, hurting both parties involved.
Do you remember The Document? At the end of this phase of refinements this document evolves to The Specification, containing details about everything that will be done.
This is the end of the first part
I hope you enjoyed and maybe learned something new. Again, I don’t aim to create any kind of guide or collection of best practices. Just some insights into our process and tools we use.
This part was oriented more towards the communication with clients. The second part will be more about tools and collaboration. Make sure you follow us so you don’t miss it and don’t forget to hit that green heart 💚.
Thank you!
