Swifty
So fast it flies
codename busy bus
Table of Contents
4
Examples of wireframes & prototypes
Wireframes & Prototypes
5
Other things not mentioned earlier
Visuals & More
1
Briefly covering project requirements
Project Requirements
2
Some research that was done for the project
Research
3
How these sketches and flows came to be
Sketches & Flows
Project Requirements
1
A brief review
Requirements
Our Client is a transportation agency for a midsize metropolitan area in the Midwest.
They requested:
They budgeted one additional feature if time allowed
Research
2
Some research that was done for the project
Research
This was used to understand strengths, weaknesses and more
We gathered survey results to understand needs & desires
Interviews were conducted for more in-depth knowledge
User Interviews
We used many methods to gather research
Competitive Analysis
SWOT Examples
Moovit
City Mapper
—User requested feature
“More communication. I'd rather have too much info than not enough.”
Survey Insights
Some insights from survey results.
The majority of people ride the bus for accessibility reasons. The majority of my survey users did not know what I meant by accessibility.
Adding examples would have helped my survey.
The number one reason users used the bus was to go to events. This was followed by school & work. This may be why Bus scheduling & routes, Real time bus arrival (RTA) info, and Trip planning were the most requested features.
1
2
Survey Insights
The two biggest requests to improve public transit was to ensure buses arrived on time more often and safety concerns. Perhaps after MVP we can look for additional ways to address this. I addressed time by including real time info and suggested a news & traffic feature.
The majority of public transit updates & info came from apps (72%) followed by websites. Websites should direct towards the app as much as possible and apps should limit website use.
3
4
48%
The amount of users who use local transit apps
The amount of users who use public transportation because it is accessible
68%
89%
The amount of people who use apps for Bus scheduling & routes features
Clip from a user interview
I recorded them on video and passed the video through a transcriber
Some Results
With gathered data we created personas, empathy maps and more.
This one for example was based of my user interview
Sketches & Flows
3
How these sketches and flows came to be
User Stories
Flows
Stories were created to understand tasks and flows
Sketches
Sketches were created to understand possible user flows
A technique called 4-up sketches was used for rapid brainstorming
Flow Chart
A flow chart was created for an overview of the app.
The flow chart ensured the main requirements were met.
This was then used for user flows
The ability to see bus schedules and future arrival times.
Time to bus stop & bus expected arrival times are included
The ability to see bus expected arrival times is included.
User Flow
Basic flow user
Detailed flow user
This flow covers simple route planning & navigation
User Flow
Detailed flow user
This flow covers two of the business requirements
-The ability to tell how much time they have to get to a stop before a bus arrives.
-The ability to tell when any bus arrives
It also is ADA prepared for any future Paratransit options as the nearby route feature defaults to ¾ a mile, making it easier for paratransit users to know if they qualify for assistance.
User Flow
Detailed flow user
This flow covers two of the business requirements
-The ability to tell when any bus arrives
-The ability to see bus schedules and future arrival times.
This info is covered in the route details page that lists all stops and expected arrival times.
Wireframes & Prototypes
4
Some future plans
App Map
The user flows helped to create an app map
Wireframes & Prototypes
They will feature:
Some considered ideas if time allows: (Only 1 will be chosen)
Examples of work
Close ups of early versions
More examples of wireframes
Changes over time
A sample of my final screens
While working on this project, there were many places in my wireframe and prototype I changed direction as I gained more feedback and insight.
Multiple paths that I considered during the project
Here are 2 places where I changed direction as I used divergent thinking:
Scheduling layout & design
Originally, I was just going to use a default bus chart, one that you would find online.
I thought it could be designed better though, so I decided to change my direction after some thought to add more clarity.
I did research on how to lay out charts and graphs, and came up with an idea on how to add clarity. From here I tested out different versions of it, and came up with a version that would be easy to read.
I tried to create a version easy to read for people with reading disorders or limited eyesight.
Bus Stations & Bus Routes
Here are four screens that seemed very similar to other screens in my design, I thought they could be reduced and merged with other screens.
So I ended up rethinking my bus stations & bus route screens to try and add clarity. I ended up with 2 screens after thinking about how to improve.
I was able to reduce my screens from 4 to 2 screens and added a lot more clarity.
I did this by merging the screens with overlapping functionality.
I also went back to the drawing board thinking about how other bus apps layout worked and decided to create something that fit more of the standard.
I continued to iterate on the design as liked the change of direction.
Usability Tests
Two different useability tests were performed.
One over zoom with comments, another with an online tool, seeing if users could follow paths.
This allowed for both qualitative testing and quantitative results.
Zoom Recording
Maze Metrics
Usability Tests
A small sample of some Zoom Results
I included some Free Exploration questions to see how they felt overall about the app, some Visual Affordance questions to see if my buttons seemed clear enough and some Expectancy questions to see what they thought about some buttons did -especially on the footer.
I encouraged them to talk out loud.
Usability Tests
I ran these for Performance Testing and to understand how well users would understand my app without me asking so many questions.
Something that would have improved results was question order and phrasing.
Usability Tests
Heatmap example
Success by screen
Total success of path
Usability Tests
User paths
Usability Insights
Some insights from Maze results.
My second question was not phased well. This resulted in a very high bounce rate. Users were so sure they were right they would repeat themselves multiple times.
Ensure users had alternative paths allowed tests to 100% successful rate except the second question, the only one without an alternative path (that led to a very high bounce rate).
People stare at my screens more than I expected. Time on tasks varied between 15 seconds to 160 seconds. Reducing info on my screens would help.
1
2
3
Visuals & More
5
Recommended steps to look forward to
Moodboard
Reasoning behind the moodboard was it was a play on words. Swifts are one of the fastest flying birds, if you combine that with airports you can say this app is faster than a plane. A lot of the coloring ideas came from airports as that is a familiar way to travel.
Style Tile
Logo ideas
Final Mock Up Video
Soon To Come
Visual branding
Because we want to stand out
New docs that aid in translating the designs into actionable tasks
Technical Docs
To ensure future content meets our standard
Visual Guidelines
To ensure the project stays on course and within budget
Project Timelines
Summary
What I learned:
What I would change next time:
Appendix