Being part of the team that developed the Fueltrip app at 3S Studio has been one of the best experiences I’ve had in the past year regarding work. I learned a lot in terms of design & development, shaping and improving the outcome of the project as we went along. In this case study I want to talk about the challenges this project faced and how I dealt with them from a visual and interactive point of view. From concept to working prototype, I’ll try to argue my decisions and make sense of all that the Fueltrip user experience stands for.
Purpose & challenges
When we were first approached by Cristian Toma for this project, the specifications were pretty clear: develop an app that enables the users to search for gas stations and view their prices, while allowing them to filter the results by certain fuel types. Sounds simple enough? Not necessarily. As things were being written down, variables came into play and the concept started to grow more complicated as more unclear situations arised: native or hybrid? use GPS positioning or searchable addresses? how far out should we search? what if the prices are wrong? who adds the gas stations? We needed to talk things through and figure out what stays and what goes and for what reason.
Because the app was mainly created to be used on the road, users would expect a simple interface with the minimal of input on their part before spitting out the results they were looking for. One of the main concerns was also reducing – if not eliminating – the learning curve so they get to have a good experience right from the start. In order to do so, I tried to follow best practice guidelines as much as possible, keeping it simple and intuitive: top bar displaying your current screen title, back button and a menu toggle for all-round access.
The user profile
At the beginning, we were considering developing the app for international users, but later decided to target only the Romanian audience (keeping in mind plans to expand afterwards). We were also debating whether or not user accounts should be required. Having an account is indeed a hassle for the user, however it does leave room for saving settings (remembering the language, gas companies, fuel types etc.) as well as for future upgrades (new gas stations submitted, gas price charts, best deal suggestions etc.).
So we decided to go for the accounts, in which you have to login at first launch and we used (almost) the same form for creating new accounts and for recovering lost credentials – preventing you from logging in. The audience we were targeting with this app was very diverse, from people spending a lot of time on the road, to those planning a road trip and even the casual driver needing to fill up the tank. This meant the UI had to be simple and self-explanatory and where it wasn’t so we’d have to cover that in the tutorial section displayed at first launch.
Handling the search
The main purpose of the whole thing was that it provided valid search results in relation to what the users wanted to find. To make this happen, all they should do is to pick the companies and fuel types they’re interested in and the rest is just details. So we needed two screens to enable choosing of gas companies, fuel types and an extra screen for the other details (location options). Now the first two are basically the same: a list from which they choose options that will alter the search results. Depending on which companies they choose on the first screen, the fuel types will be filtered on the second one (i.e. only fuels from the selected companies will be displayed).
On the last screen of the search filters, we only included options for specifying the search radius and for choosing a location point at first. This could either be their current GPS position or another address editable through an input field, with automatic results being queried as you typed. Later on, we had to also integrate a route option and find all gas stations along that route, within the radius of any given point on it. The start (A) and finish (B) points would be filled in just as a single address would.
Displaying the results
With all the search filters ready, the users could now get the results they needed displayed on their screens. The default display mode is by map, so it would be easier for them to estimate distances between themselves and their gas stations of interest, plus it’s also easier to get a bird’s-eye view on the entire set of results, without having to get into details with each and every one of them unless they want to.
Getting into details
One of the things that was clear right from the start was that upon tapping a gas station marker on the map users will be presented with a modal window displaying all fuel prices for that particular gas station. Here they could see the fuel types, prices and elapsed time since their’s last update. In the case of incorrect pricing, we introduced the option of editing them on-the-fly, thus creating a community that would contribute and keep the prices updated themselves.
Let the user choose
For a more comfortable usage, we also introduced another display method for all the search results on the map. What this list display accomplishes is give an improved overview of all prices for better comparison. The layout used in the list is the same as from the previous gas station modal and therefore avoids having to make the user get accustomed to yet another interface. Initially created in individual boxes, each gas station’s container required extra padding and margins for an improvement in white-space. On the other hand, this raised an issue with smaller device screens which meant that font and button sizes needed to be reduced to fit all content without line-breaking.
Obviously smaller font and button sizes then lead to bad readability, so in the end I decided to drop all containers, borders, padding and margins and just display the gas stations one after the other. This gave me more room, the overall look had more breathing space and the interface wasn’t as fragmented as before.
Building a community
The most important feature of the app, besides the actual search options, was to let users keep the database up to date by themselves in matters of gas stations and fuel prices. But what about gas stations that aren’t in the database? There is no way of monitoring where or when they pop-up and what their fuel prices are, so to solve this we added the ability to use a location in order to submit the new gas stations users came across on the road. For best results, we only asked that they zoom in enough on the map to get the coordinates as accurate as possible.
After having chosen to add the new gas station, everything is pretty straight forward: for any gas station to be valid we require that at least one of their fuel types has a valid price. At first glance the submission form might seem a bit too demanding of the users, but once again we needed to reach a compromise between the amount of information we needed and the input we asked for from them (hence asking for a minimum of one fuel price instead of all of them).
Before submission of the newly found gas station, prices can be added, edited or deleted, however we limited the number of fuel types to that of the selected gas company. For example if one company has 3 fuel types and the user chooses to add a gas station for that company, they cannot add more than 3 fuel prices. Also, once a fuel type has been selected for a price it is automatically removed from the rest of the list, to avoid confusion or possible data corruption. In the future, we might also consider adding even more features to better improve the sense of community within the app’s users (dashboards, reports etc).
A custom experience
The easily accessible settings screen allows users to change their credentials or adjust their custom filters from one single section. For the original wireframe, I was considering splitting the options into “Account info” and “App settings”, but this would have meant another step the users had to make in order to get to the tab that was not active at the moment. Instead of doing that, I’ve placed all options on the same page for quick access. Except for the filters (companies, fuel types) all other options can be changed on the spot, without having to leave this screen.
Navigation & flow
On the initial concept, the main menu was only being brought out when viewing the search results, because I thought there was no need for it elsewhere. Obviously after getting a bit more into the UX of the app, things changed and the menu was no longer this elusive. The first thought was to only show the options most used in the top menu and display the full list only upon request (tapping the “More” button). This however lead to several problems, as the buttons wouldn’t scale properly on different screen sizes and there would also have to always be exactly 10 buttons – no more, no less – to preserve aesthetics. In turn, this translated into filling up the menu with unnecessary options.
Moreover after needing the menu present on other screens, this top positioning wasn’t such a best practice as the toggle button would overlap with the title-bar and once again, the minimum number of buttons inside the menu had to be of 5 or 10. As with this menu concept, another UI element that got lost along the way was the filter screen. Users would have to tap the “Menu” toggle button, then the “Filter” button, the choose a filtering method and only then would they be able to change the settings for that filter from the new screen. Not very good UX. That’s why iteration is so important; going through the interfaces over and over again and figuring out what elements could be recycled and how. Here is where the new menu layout came into play.
As mentioned in the section where I discussed the search results, we used the Google Maps API to render the map and reproduced a small part of their mobile map UI so as to offer users an easier way to get familiar with the Fueltrip interface. With this in mind, the top menu has also been redesigned to slide in from the left, thus resolving basically all of the issues from its previous version: we could have any number of items, it was completely scalable and accessible from any of the screens. Even more so, it played very well in regards to the brand color.
Iconography
I’m not going to go into the details of what purpose icons and symbols have in apps and websites, as that ground has already been covered by many others with far greater experience than me. I will however say that with the design of this app I was striving for simplicity and getting the point across (as is noticeable in the app icon itself). The icon set used throughout the app is Font Awesome, a project created by Dave Gandy, which to me seems one of the best resources for designing in today’s web. We obviously only used a subset of the font, but the glyphs that were available have indeed done the job right.
Now in terms of map markers, I maintained the overall outer shape of the modern Google Maps marker and adjusted the fill colors to match the Fueltrip brand for the default and company marker, while the rest are colored differently depending on their purpose. From point A to point B we have start/green and stop/red, as for the current location I kept the color from the API, applied it to our marker template and added the location symbol to it, thus creating a relation between this marker and the “current location” button on the map.
Showing it to the world
Considering the fact that the app could in the end run both from web browsers as well as from the smart phone app itself, we went about creating a homepage where all official Fueltrip information could be found: features, sign-up form, help etc. While thinking over the design, I managed to sketch something up as I saw fit at the moment. However, as with the app itself, the website was adjusted and refined until it took the final shape you see bellow.
Now because we wanted to also target people who are reluctant of installing new apps or those who perhaps want to only try it out at first, we knew that using Fueltrip as a web service would be an important part of the project. This meant that the website would without a doubt have to be responsive and scale accordingly to fit various screen sizes. This was made easy by using a custom mobile-first Bootstrap 3 framework from Twitter, so now users have a great experience no matter the device their own.
Wrapping it up
With its ups and downs, its challenges and resolutions, the Fueltrip project has been a real game changer for me as a UI designer. I’m happy with the outcome and have learned a lot along the way, as can be seen from the changes that I’ve constantly applied to the interfaces, from wireframe to final working prototype. The team at 3S Studio worked very well together and managed to put into motion this very interesting and helpful product of which we are all very proud and which happens to be the very first mobile app project I’ve worked on. Launching of the app will take place soon, so keep an eye out for any updates over at www.fueltrip.ro.