This is part two in our series on the process of how we work to develop the best mobile apps in New England. Check out Part One, Discovery, before you continue to read about how we do Design.
Once our Discovery phase is complete (though honestly, we never stop mining for more information as development continues), it’s on to the Design phase of our partnership with the client. But here’s the trick: Design is less about the client, and much more about the client’s customers – the end users.
When we talk about “design,” it all starts with the idea of what user experience (UX) we want to give the user. Sure, we can debate shades of blue until the sun goes down, but at the end of the day, if the UX is bad, no amount of gloss and sheen is going to cover over a poorly designed app.
Here at the Farm, good Design first means good UX. This is why we start by focusing on who the user is:
- What is their persona? Their name, occupation, and details of their lives?
- What are they trying to accomplish with the business as a whole?
- What does “success” look like for the user?
If our client already have these personas in mind, that’s great. If not, we will work with clients to develop them. Either way, we’ll make sure that all parties are on the same page as to the prototypical “user” or “users” that we’re catering to.
Everything, all Design decisions, point back to the user experience.
The Design journey starts with a robust task flow which we call the Experience Map that represents the key paths through the usage of the idealized app. The Experience Map helps both us and the client visualize the user’s progression using the app over the key flows, so we can identify the various screens that need to be created. Key flows include the welcome screen, the onboarding process for new users, account creation and management, the core app functionality, and even logging out processes. We map out all the types of screen variations the app will display in daily use.
Once we understand the map the user’s journey as they navigate the app to their goal, it’s like we have dug a road to the destination. Now it’s all about paving it to provide the best possible ride. To that end, we work toward functional wireframes that are black and white skeletons of the app. Not only does this help us conceptualize the overall UX, but it provides a very easy way for the client to provide additional notes and requests.
Wireframes are deliberately black and white so that we can focus on the hierarchy of information without getting caught up in colors and images. Clients are always eager to get to the visual, but without finishing wireframes, we end up with a journey that’s confusing, even if it looks pretty. Each wireframe balances the placement of text and controls so that we can call the user’s attention to the most important elements first. On every screen we need to provide users with 3 things: the information they need to make a decision, the actions they can take, and feedback after they’ve taken an action.
We’re strong believers in detailing every part of the app through Wireframes, so we have a complete picture of what the app is going to do and how the user will be affected.
The next part of the Design journey encompasses the visual and branding aspects of “design,” meaning, the look and feel of the app. And this is the fun part for both sides. Because we get to really release our creativity and years of experience to come up with design elements that are unique, eye-catching, and gives that ‘wow’ factor that can often make the difference between an app you open once, and an app you can’t live without.
While there are dozens (if not hundreds) of Design elements to consider, there are key aspects that we consider first, including:
- Visual clarity in navigation
- Natural and finger-friendly approach to user gestures
- When to engage the user, and when not to
- Funneling the user to the ultimate goal of the app
- Animations and sounds that enhance the design
Of course, throughout we are incorporating the client’s brand: colors, fonts, logos, images, language, and personality. To start, we always create “mood boards,” collages that combine those elements (color, font, images, etc.) that establish the overall feel of the brand. We’ve found that mood boards help clients to make high level decisions about the design elements – we get the team pointed in the right direction. From the mood boards then we can create “comps” of 1 or 2 of the key screens to make sure we have the right design direction. Iterate and refine – and then on to all the other screens.
Nothing we Design is white-labeled; everything is unique and custom to each brand. After all, your mobile app is a direct extension of your business, if not the tip-of-the-spear.
And what better way to impress and delight your users with tactful and timely animations, which can further enforce actions and the experience, and sound, giving your users feedback. All these aspects contribute to a world class app that is the essence is your brand.
But all this creativity isn’t just reserved for what you see.
At the Farm, we put just as much creativity into the back-end architecture of the mobile app as we do the user-facing front. No two apps are the same, and we daresay even more of our expertise goes into the back-end: a pretty app won’t mean beans if it runs slow or breaks.
So a large portion of the Design phase is to design how the overall architecture will be built: the composition of what the user sees and experiences from a) a client app running in the user’s hand typically on iOS and/or Android, b) a backend system running in the cloud, and c) all the other support elements needed for additional touchpoints with your user. This last category includes aspects of operational infrastructure that many clients don’t typically think about: customer tracking/management systems, push notification and email notification systems, even support systems. We think about these things from the beginning because you’re not just pushing an app – you’re running a fully functional business.
On the client side there are decisions to be made about running native and which language to use. For example on iOS you can code in Swift or Apple’s older language Objective-C. On Android we can either code in Java or Kotlin. And in both cases an alternative approach could be a cross platform language like React Native (link here to our post), which in lots of cases can work on both iOS and Android from a single code base. The options are the science; the choice is an art. There are legitimate reasons to use one language over the other, and it all depends on the combination of the client’s established back-end system, the objective of the app, and the user experience.
There are a gazillion ways to build out the back end system and it again all depends on our client’s existing infrastructure and overall technology strategy.
We work to balance latency, throughput, and response time with the data-heavy demands of today’s mobile apps. Sure you want the app to do everything on the latest iPhone, but what about users who are using 3-year-old Androids? It’s system-level Design that addresses these issues, and we’ll make recommendations to build the app in a way that considers speed, load, and functionality. We also routinely design in systems that do specialized work like process payments, let users sign up for subscriptions, and orchestrate business workflow.
All said, the Design phase will take about four weeks to complete. And we’ll interface with the product owner, marketing, engineering, and operations to get a holistic picture. Once this is done, we’ll have a great wireframe as we launch into the third phase: Development.