Richard Picot | UX Designer
Portfolio
swifty-banner-overlay_mini.jpg

Swifty

Duration: 2 weeks

Tools: Pen and paper, OmniGraffle, POP, Sketch, Marvel

Working solo

 

Project Overview

The Client

Tom is a 29 year old Teaching Assistant from London. He loves meeting up with friends after a long day at work.

The Problem

After a long day at work Tom loves to make plans with friends. He uses his iPhone a lot throughout the day, but no matter how many chargers he brings, he always seems to run low on juice at the wrong time making finalising plans a stressful and rushed experience. Often resulting in not being able to get a message out to friends quick enough.

The Brief

Working with a client, identify a pain-point in their life and design a mobile app that helps address it.

I chose to streamline Tom's messaging workflow with a mobile app that makes sending meet-up messages to friends quick and painless.

The Process

Discover

User Interviews
Concept Mapping
Storyboarding
Task Analysis
User Flow

Develop

Sketching
Paper Prototyping
Low Fidelity Clickable Prototype
Brand Personality Framework
Mood Board
Icon Sketching
Style Tile
High Fidelity Mockup
High Fidelity Clickable Prototype

Test

Paper Prototype Testing
Clickable Prototype Iteration Testing
Product Reaction Cards

The Solution

  • Messaging is quick due to the heavy use of gestures.
  • Aided further by reusing information
  • The visual design of the app aims to take the stress out of the context.
  • I chose not to focus on solving the deeper issue of battery drain as iOS9 has a low power mode, helping to alleviate the issue.

Main Challenges

Developing a solution that solves the needs of an individual client whilst avoiding scope creep or making a niche product.

Process Highlights

Putting into practice a number of visual design methods that I had not used before, all with the aim to help define an aesthetic that reflects how you would like the user to feel interacting with the product.


--Case Study--


Discover

No matter how hard I try, it always seems to be a mad dash to let everyone know the evening’s plan moments before my phone dies.
— Tom, the client

Interviews and User Research

Interviewing my client I was able dive a little deeper into the problem and bring some useful details to light.

  • His friend circles tend to meet at the same selection of places regularly.
  • He communicates with these social groups across multiple messaging platforms. (For work friends he may go to WhatsApp and for builder friends Facebook Messenger).
  • His communications tend to be roughly the same format but with varied pieces of information such as the message details, location and ETA.
It’s made harder with the different groups of friends using different apps.
— Tom, the client

Concept Map

Concept mapping allowed me to get a broad picture of Tom’s day.

My original idea was to dive deeper into solving the battery drain issue but very quickly realised there wasn’t much more I could offer than a heavier notification based system for battery alerts than that built into iOS. It is also worth noting that with the introduction of iOS 9 low power mode aims to help alleviate battery usage.

I chose to put my focus on streamlining Tom’s messaging workflow.

 


Define

User Flow

User flow

It was evident that there were a number of choices at the heart of the problem contributing to the overall time taken to send a group message.
The process is further fragmented in an instance where Tom needs to jump into Google Maps to lookup a nearby location, calculate an ETA and paste those details into the message. This is best visualised in the below user flow.

 

My Proposal

I decided to focus on a solution that was all about saving precious moments in this pressurised situation. In this case Tom’s trigger is the realisation his battery is running low, but the pain point remains the process of getting a meet-up message together quickly.

My intention was to create an interface that was heavily focused on:

  • Simplicity
  • Fluid and intuitive interactions
  • Relevant info at the right time
  • Reusable information

Develop

I came up with the idea of using a reusable card based system. Each group would essentially have their own message card that contained four fields for input:

  1. recipients
  2. what the message says
  3. the location to meet
  4. and a rough ETA

Once a card has been set up, it can be reused again without having to input the information into the fields. However, edits can be made when necessary.

To further speed up the process, location and message fields will have a swipe action that can change the content to another previously used message or location.

 
 

Paper Prototype

Through the first round of paper prototyping I was able to gather valuable feedback on the interface sketches. A number of changes where made but most notably the ability to add a new blank message card anywhere from the main screen.

the ability to send a message at any stage of writing, thus catering for a scenario where location and ETA are not relevant. Prior to this the option to send only populated after all fields were completed.

 

Low Fidelity Clickable Prototype

Having iterated the sketches I used POP to create a low fidelity clickable prototype.

It's features are:

Aggregates existing messaging services by pulling in groups and contacts saving the need to jump between multiple messaging apps
Learns previous entries so that locations and messages can be reused with a swipe, no need to type!
Looks up locations from within the message screen, no need to jump to a different app
Sets a rough ETA based on current location and distance to destination
A typical received message sent by Swifty may look like this, “Hey guys, my battery has died. Let’s meet at The Clerk and Well (https://goo.gl/maps/ayYbQiGdD1H2) I’ll be about 45 minutes.”
Messages include a link to the location via Google Maps


Visual Design

Research

Having designed a low fidelity prototype of the app that had been refined to suit the user journey I was able to turn my research solely to visual identity.
I started the process by interviewing my user to find out if there were any apps that he found aesthetically pleasing. Pocket, Medium and Trello became good frames of reference. These apps use a lot of whitespace to convey their simple and easy to use nature, with splashes of colour to bring attention to key elements.

 
pocket, medium and trello
 

Defining Visual Design Goals

I revisited the purpose and circumstances of use for Swifty. I was then able to form a number of goals for what I would like the visual design of the app to convey.

From my initial research I knew that my user would likely be rushing and under a fair bit of stress during use, I wanted to focus on combatting this with my choice in aesthetic. My goal was to create a visual that followed these key words:

  • Calming
  • Confident
  • Reliable
  • Stress-Free
  • Playful
  • Funny

I also used the Brand Personality Framework to help define the following statement to further cement the app’s identity;

Swifty is Intelligent, down-to-earth but never technical.

This statement alongside my existing goals gave me a framework to judge each decision I made in the visual design process to work towards.

I intend to utilise any copy in the app to further enhance the friendly but confident voice and tone for the app.

 
 

This mood board helped me start formulating visual ideas from my defined goals.
To help guide my iconography I used the keywords of my brief (quick, messaging) and came up with associates objects. With this on paper getting the ball rolling on sketching app icon ideas was also a lot easier.

Style Tile

Centred on the adjectives I outlined in my visual design goals I started to create a style tile that would help convey this utilising an appropriate typeface, colour palette and choice of icons.

Building the Mockup

I used Sketch to implement my style tile into a digital mockup.

My initial digital mockup followed the original design of my paper prototype. However, following a design crit I found that the visuals seem to fall a little closer to the fun and playful side of things, due to this the perceived reliability and confidence of the app was lacking. Every interface element was rounded, I believe this has something to do with this perception. User feeedback was also that the information in the card composition screen was a little clustered.

I chose to combat these factors by making a number of changes to the interface. Most obvious was the change to the layout of each card. I removed the rounded edges and split out each section in the card to make a cleared divide between each field.

I validated my visual design goals by performing a short survey with users, asking them to pick five adjectives that best describes their interaction with the app. Simple, friendly, fun, comfortable, relevant, easy to use, relaxed and modern were all words used by users, all closely inline with what I set out to achieve.


Prototype

This animated version of the iPhone prototype follows the key screens to sending a message through an existing card, editing an existing card and creating a new message.

Being a message solution that is all about short focussed interactions, Swifty seemed like the perfect case for building a prototype Apple Watch app. I extracted and simplified the key screen and created an Apple Watch prototype app.

 

Summary

This project for me was heavily about the visual design phase, it was something I have not done in such depth before. The techniques applied to set out an identity really worked well.

If I where to continue working on this project there are a few future considerations that would make Swifty smarter:

  • Ability to set a trigger so that messages are sent automatically when leaving a predetermined location
  • Data detectors to make suggestions based on existing messages in other messaging apps
  • Better scope of use for communication when the phone battery has died. Possibly a telephone relay service

Looking Back

There is one thing I would do differently if I where to do it again. I previously outlined why I chose not to dive into designing a battery management app but arguably it would get deeper to the root of the problem. I would spend a little more time researching this idea.

Thanks for reading! 👌

 


< Back to my work

More Projects