The Brief:
We were approached by CityMaas Assist to design the UX and UI for their mobility application. CityMaas Assist is a technological platform that aims to provide city travel information. Their primary users are people with varying abilities and disabilities and they want to provide unique features aimed at these groups particular needs.
Intro:
People with disabilities and difficulties have to face constant struggles on a daily basis. This can often lead to them feeling frustrated and isolated. This is especially true when it comes to travel and getting around from place to place. Accessibility and inclusion are often not sufficient for a persons unique needs and they can frequently find themselves stranded and without assistance. We believe it doesn’t have to be this way.
Technology has evolved to a point where people have access to endless and unlimited opportunities. Unfortunately it doesn’t always include access for everyone, such as the visually impaired or the hard of hearing. Accessibility in technology needs to consider all needs of all people.
We propose to create an application that puts the unique needs of all persons first and considers everyones individual requirements. In this way people will feel empowered to do the things that they couldn’t do before.
What is the primary purpose of our application?
‘TO ALLOW PEOPLE OF ALL CONDITIONS THE FREEDOM OF CARE FREE TRAVEL’
The Team:
UX: Elena Lo Piccolo, Omar Ali
UI: Jimmy Hay, Kate Tsurik
Tools Used:
Pencil, paper, Sketch, Adobe Photoshop, Adobe Illustrator, Invision, Keynote
UX
Contextual Enquiry
This step in the UX process was for Elena and Omar to collect as much information that they could about users and the kind of issues that they have getting around the city. They carried out a contextual enquiry where they spent the afternoon with one of the founders of CityMaas Assist who was wheelchair bound and also couldn’t use his arms. They travelled with him on various modes of transport including buses and taxis to get an idea of the pain points that he encounters and the kinds of features that would help him.
Survey Affinity Diagram
After carrying out their user research the UX team created an affinity diagram that gave them a good overview of the audiences needs and the main pain points that users were confronted with. This helped them translate the key insights from their previous research into valuable and organised systems of data.
User Persona
A user persona was then created to represent the apps typical user. From this we were able to deduce the typical journey that a user would take, their pain points, goals and emotional needs. This helped us to get a better understanding of the specific needs of our users and how we might be able to solve these problems.
Storyboard
Elena then created the storyboard that illustrated the story of a wheelchair user, John, travelling through London. From this storyboard we were able to pick out specific features:
- Using an app like CityMaas would allow him to plan his whole journey from A-B with detailed information specific to his requirements.
- Allow him to book and pay for his entire journey before he sets off all from 1 application.
- He would like to have real-time updated information sent to the app on the availability of wheelchair access throughout his entire journey.
- He would like to be able to call for assistance at any time directly from the app.
User Flow
A userflow was created from the key insights obtained in the storyboard.
Low-fi Prototypes
From the userflow we were then able to start thinking about the low-fi prototypes and the necessary components that would need to be on each screen.
Mid-fi Prototypes
The mid-fi prototypes were created and mapped out a user journey from the moment they open the app and select a route, begin their journey on this route, receive a live update with information about their journey, are asked if they want to pay for a ticket in a tube station and the payment process through to arriving at their destination and completing their journey.
UI
Moods
To begin the UI design process we first brainstormed ideas on a design inception worksheet. We ended up with 2 separate moodboards, each with their own direction. The moodboard on the left was more facilitating, informative and intuitive. It was heavily influenced by wayfinding and navigational graphical systems. It features quite a lot of swiss style typography that is very functional and clear and is very good at giving clear directions. The right most moodboard was influenced by empowerment, confidence and supportedness. It was the more emotionally driven moodboard and contained quite a lot of illustration and a softer colour palette.
Style Tile
From our 2 moodboards we were able to start working on the style tile. We decided to use the functional, informativeness of the left moodboard to create the main UI elements that would be provide and clear and concise visual language aimed at directing people where to go, making them feel assisted and at ease.
Typography
For the typography ‘FS Me’ was chosen as the typeface. This particular typeface has been especially designed with accessibility in mind. It has been designed for people with learning disabilities and takes into consideration the shape and position of each letter and glyph. For example, the dot’s over the i’s and the j’s are slightly enlarged with makes them easier to see.
Colours
The colour palette we chose was directed by our accessibility criteria. We discovered through our initial research that certain colours were not available to use due to people with colour blindness and also people with autism. The colour yellow was ruled out since it can affect people on the autism spectrum and tones of orange and red were off limits dues to colour blind limitations. We also had to maintain a high level of contrast on all of the screens and we were able to check these using the WebAIM colour contrast checker. Our final palette consisted of a strong green colour that we would use for the majority of the buttons and CTA’s and then a dark bluish grey for the background. We also had a brighter blue colour that would be reserved for more important CTA’s.
Layout
The layout was kept clean and concise in order to not confuse the user at any point. We tried to keep information on each screen to the minimum because we didn’t want to overwhelm people who might be sensitive to too much information at once. The directions on the navigation screen were deliberately kept as simple as possible with the most important aspects of the instruction capitalised and in a larger font size.
A tricky part of the design was finding out the most concise way to accommodate the live update prompts and step by step instructions all on the same page. Because it was such a large amount of information required I had to place these items into sliding trays that would be accessible when the user required them. I feel like there might have been a more elegant solution to discover had I had a bit more time to explore other options.
The client had requested that there must always be an S.O.S button present that is visible on all screens throughout the app. This was so that the user would be able to access assistance at a moments notice should they find themselves in any difficulty. From a UI perspective, this proved slightly tricky to accommodate into the layout because it needed to be clearly visible, but not obscure the main content in view. I tried a few different options for placement of the button and different colour options. We ended up choosing the top right corner and went with the light blue colour. This meant that it was always visible and stood out, but didn’t get in the way of any of the main content.
The sizes of the buttons and interactive elements was something that we had to consider. Apple’s Human Interface Guidelines recommends that all touch targets are at least 44pt x 44pt. Because our users could have visual or motor impairments, we decided to make our buttons much larger so that they were easier to read, easier to use and there was less chance of pressing buttons by mistake. The iconography that we used was bold, clear and easy to understand. Any icons that we used were always combined with a text description to avoid any confusion that a user might have with the meaning behind an icon.
Branding
Me and Kate ran a brainstorming session to come up with ideas for the branding. We explored the metaphorical meanings of animals. We chose to use a dog as the symbol for our app since dogs are loyal, friendly and trusting. It seemed to fit well with the apps functionality and purpose.
Style Guide
Final Thoughts
- The most challenging aspect of the project was trying to keep the team organised and motivated. We only had 3 weeks in which to complete our research and prototype so it felt like every day was important and we needed to keep organised in order to stay on top of things. We were supposed to have daily stand up meetings each morning but we didn’t manage to do these every day and I think this meant the team felt a bit dislocated since we weren’t always entirely sure what everyone was working on. It’s an important lesson to take forward to future projects.
- We had some issues earlier on in the project when we were trying to decide on the user journey and what path would be best. We came up with some interesting ideas but I think some of these ultimately ended up complicating the project more so than it needed to be, especially since we only had to deliver an MVP. In the future I think I would push to ensure that we concentrate on the main, essential features of what is important to the end user and save the extra ideas for later development.
- Overall, I am happy with the final outcome of the project and I feel I learnt so much by working on a real client brief. It would be really great to have more time to work on this and perhaps run a few more iterations of the design process so that we could test some of our assumptions and get some feedback from real users.
