Designing for hybrid solutions

Barbara Mendes
bitmaker
Published in
4 min readNov 16, 2018

This is a three part article sharing how we developed a mobile app with Google’s Flutter. Please read part one, detailing our design sprint and user experience process, here: Part One

The software development team at bitmaker decided to use Google’s Flutter, a hybrid platform which allows for the release of both iOS and Android applications without the need for replication.

In terms of design this meant that we would be using patterns which should be intuitive for both Apple and Android users. We decided to create our own design system, based on interaction patterns already known to the users.

From our experience we know that Apple’s guidelines and publication criteria is much stricter, so we decided to use mainly iOS native interactions with a branding approach, such as colors, typography and illustrations.

Design System

Our first concern was to develop a visual language for our product, a collection of components sharing patterns and principles.

A visual design system is built out of the core components of typography, layout, shape or form, and color. When considering the design of a whole product, a design system should also include patterns in user flow, content strategy, copy, and tone of voice.

https://24ways.org/2012/design-systems/

Color

We wanted to remove the stress component out of parking, so we decided to use a green hue as the primary color, a relaxing and restful color also reminiscent of nature and harmony. The choice also made sense in terms of business goals, as one of the main objectives is to reduce traffic and pollution, the color green fits as it is particularly related to environmental issues.

As a secondary color the choice laid upon a red hue because we wanted to alert the user to certain interface elements, such as cost and cancellation features. Even so, the red used is very light and is used as a soft gradient so that the user is aware that something requires her attention but not to impress a sense of danger or unease.

We use grey as a backup color, blending several tones of blueish grey throughout the application for neutral elements, such as form placeholders, informative lists and helper texts.

Color symbols

Typography

Because we were already using a green hue as a primary color and not the obvious Porto blue, we decided to include some of the brand identity of the municipality and used their typeface Regular as our main typeface.

Imagery

Finally, we set guidelines for illustrations and iconography and created symbols

All of the above elements were created as symbols on Sketch, to be used as building blocks for our components. Following the user flows created at the design sprint process, we already had a set of patterns and key components identified and, using our visual language, the process of creating a consistent products was much swifter.

Header component variations

Creating a design system provides a clear and global view of the product’s look and feel which translates into an easier connection between the designer and the developer. It’s easier for the developer to create styles which will accommodate this visual language, already having a library of colors and typography hierarchy.

It also gives the engineering team autonomy to create new components with a consistent design and language, leaving the designer to work on the refinement of the overall product.

Design for gradual development

On our first meeting with the municipality, we realized there would be some legal concerns regarding the main features of the solution, which meant we would have to adapt our strategy and concept.

Our approach was to focus on navigation to the park and booking in advance as well as advertising the payment method, MBWay as an encouragement for users to download the application, since it is a simpler and friction less way to pay.

Our aim designing this first version was to already think ahead, so we designed features that won’t be present on the first version but that make sense in the future. This meant the application was already designed as a whole, as a compete flow for all personas identified, such as casual users, tourists and subscribers.

Our expectation is to collect user test data on this first version, to better understand if the solutions we are providing are meeting the municipality’s main goal of reducing traffic around the city center and, also, understand what is working: if the users are getting any value out of the application, which features are they using and in what conditions.

This will be a valuable assessment in order to succeed in moving forward with a polished application for the general public.

--

--