It's there when you need it, but disappears when you don't
Together with the founders we started to design the app from scratch. The app should feel lightweight. I strove for a design which brings the main components all in one screen but react depending on each other. Well in other words – it means the map is in the main focus and there are different states of elements as the user is in different types of process.
On the upper screens you can see on the left the initial screen. That's where you get when starting the app. You can see all the surrounding vehicles available. On the top the user can execute a route-search. By clicking on a pin of the map, this search bar disappears, as it is not relevant in this moment but details to the specific selected vehicle. All that is underlined by the fading like ui.
UX Stuff – the approach
When I joined the project, the guys had already started to create the fundamentals of development in terms of coding. So by my onboarding, I started to think about the general idea/story from UX perspective. I've created flow charts and scribbles together with the founders to consider multiple approaches.
As the project was part of a venture start-up programm, we strived for a MVP product. We had defined they key value of the app - providing a super simple way to find the best choice of all available providers and its vehicles to get from A to B by the available shared car/vehicle options around the user. It's pretty simple: the user wants to see where am I and where are the relevant vehicles around me? And then: Let me get it (book). I've created the flow-chart below. The left part illustrates this main purpose of the app. With just two clicks it's possible for the user to book a vehicle.
So the map is the starting point. The user sees his current position and the map with available vehicles around. The user can simply select an object on the map which reveals an info-panel. Just the most relevant information is shown directly and more info can be reached by a simple swipe gesture. With this kind of concept, we keep the experience easy and light way. You can see an early draft of this idea on the left image below.
Getting closer to the real thing: Scribbles.
After we had defined the general structure of every screen, I began to create rough wireframes. I also put them together in a flow-chart you can see in the following graphic. This overview mirrors the major flows within the app. In addidion I created out of thos wireframes a simple click-dummy with inVision. So we could experience the concept and rough experience first hand and understand better, what it will feel like.
When we've been confident with all that previous steps, and it's outcomes, I started to design the User Interface. Like I did with all the UX stuff as well, I made several iterations to gather the feedback from the team and to generate more ideas and approaches together. Some of the final screens are shown in the following graphic. I was working closely with the developers so that the communication was clear from the beginning and stagnation could be prevented straight away. I hadn't over all designs with a tool called Zeplin, which allows simple interaction for developers and other to get all information out of the design (measurements, colour, etc.).