Illustration: Agile methodology

P3 Group – Client
Application suite – Scope
Lead UX Designer – Position
6 weeks – Duration

➜ Image gallery

The "Under" application suite was created for regular taxi companies and customers. The software development team applied the Agile development methodology to an internal project within a low budget and short deadlines.

I have synchronized deliverables with the development team, guided the fellow designer, defined the visual language, designed the logo, and unified the look and feel, UI patterns and interactions of the product suite.

Color Issues

Image 3: Map color themes: Dark, Night and Aubergine

The Project Manager needed me to step in and help them out. By then, the UX colleague had created grayscale mocks for the Passenger mobile app using the Dark map color theme. Having colorless UI, they needed to define the actual UI design and to add some color as soon as possible. I suggested a more colorful map as a quick fix, but we had no time to create a new, custom map style.

I investigated available map styles, tested them with different levels of detail for Roads, Landmarks and Labels and soon identified the most colorful dark theme: Aubergine. I advised the team to use that one. Changing only the background of the app with the map theme was a minimum viable solution at that point, but it did the trick, and I jumped headlong into the project.

Pragmatic Approach

Image 4: Initial versions of light and dark UI color themes

The UI was still monochromatic, and the brand was practically nonexistent. I created several variations of light and dark UI color themes and presented it to the stakeholders. For the MVP, only one theme was going to be developed. They opted for the dark, and I offered to design the color theme for the whole suite.

The proposal was acceptable only if I was able to deliver something in a couple of days, which was impossible. My coworker was busy working on the Passenger mobile app at that time. We needed two more apps for the suite, and I proposed to define the branding while working on the actual design of the Dispatcher web app. That was much more acceptable for everyone. I needed to take a pragmatic approach and create a style in sync with the Aubergine map theme.

Logo Evolution

Image 5: Logos within the dark UI color theme

The PM informed me that the Managing Director, who initiated the project, was not quite satisfied with the logo that PM and my fellow designer have put forward, and they wanted me to improve the logo as well.

All the elements had to be in harmony with each other, so I started working on all of them simultaneously: I have created several logo variations and tested them within dark theme designs, while updating colors, icons and other UI elements. We had evaluated the logos in their actual context, decided to have one logo for the whole suite instead of different logos for each app, and picked the winner. Stakeholders were quite satisfied with the solution and welcomed the new logo and the new UI styling.

Correlated UI Patterns

Image 6: Logo, selection, list, map, etc. in web and mobile UI

Not only do Android and Web platforms differ, but our applications also had different functionality. We couldn’t possibly have the identical UI elements and interactions applied to them. Still, I made sure we use corresponding paradigms and visuals on all platforms throughout our product suite.

For example, the current screen selection in the mobile menu featured a pattern that closely resembled the list item selection for the web application. I advised my teammate on how to use such correlated UI patterns and how to apply the common visual properties and colors onto the existing mobile UI patterns.

Consistent Look and Feel

Image 7: Imaginary stylesheet, not created during the project

My coworker was more of a UX than a visual designer, but quick to understand and apply the necessary styling once I explained what we’re trying to achieve. We did not use any stylesheets, brand books or style guidelines.

We had our hands full with the product design and no time to create internal specs. We were exchanging Sketch, Illustrator, Photoshop and other files through a cloud storage, with a lot of verbal communication. I have shared Illustrator files with all the branding elements, visual samples of application’s look and feel and named color swatches, as shown in the Image 7.

Consolidated Interactions

Image 8: Analogous interactions for touch, mobile and web

I advised implementing consolidated interactions for web and mobile by creating analogies rather than imitating other platforms, as shown in the Image 8.

Web & touch (column 1): text box with emulated keypad, send button available. Mobile (column 2): native text entry and keypad, send button available after the keypad is dismissed. Both keypads promote a confirmation checkmark button. Web on desktop (column 3): mouse interactions with hover and press states. Mobile (column 4): mobile-specific swipe interactions prevent accidental confirmation of ride and payment requests.

Views and Permissions

Image 9: Different views for apps, roles and permissions

Image 9 shows Dispatcher, Passenger and Driver apps. The Dispatcher app makes use of disabled and enabled input fields, read-only and editable images, as well as hidden and visible links and buttons – depending on the permissions.

Each role was interested in different information and needed distinct actions to perform disparate activities within their apps. As a consequence, applications in the suite were applying different views. Each view depended on the conditions it needed to satisfy. The web app was affected by the additional permission level for Managers, and with the fact that users couldn’t change their own permission level, delete or block themselves.

Visual Artifacts

Image 10: Android icon, map artifacts, web and mobile icons

I had taken the logo, applied the appropriate clearance and created the Android icon for the mobile applications. Swipe interactions were essential for their functionality, but I noticed that swipe icons usage was inconsistent throughout the interaction sequence: the apps needed more icons than we had available.

I volunteered to provide the missing icons for all the products. From a purchased set of icons, I took the existing ones for warning, trash can, and pencil. I slightly changed the magnifier, arrow, send and checkmark icons. I significantly modified the car, user and request icons. I have created from scratch the riding icon and all the other visual artifacts required for the web and mobile apps.

Design Elements

Image 11: Free fonts and photos, purchased icons

In an Agile environment, designers must deliver visual artifacts as quickly as possible. We were moving fast with a small budget, so free stock photos were the obvious choice. They also served as a mood board that we never created.

Finding the right logo font wasn’t easy. I had run into Aldo Semi Bold while browsing at home. It seemed right, but I wasn’t sure until I tested it at the office. It was completely free and I eventually used it for the wordmark. Aldo was not at all a font that is suitable for text paragraphs, so I chose the Roboto font family for longer sections of text. We designers also had to find free product design elements for users, cars, printed materials, animations, etc.

Documentation and Meetings

Image 12: Minimal specification, whiteboard drawings

The Agile methodology does not eliminate the need for specifications, but in this project the documentation was quite deficient. And in the field of design it was almost nonexistent. The minimum specification was originally written as an extremely short document. Conclusions, open questions, answers and remarks were added later as the result of meetings and consultations that followed.

Every morning we had a 15-minute stand-up scrum meeting. After that, if some things were not clear, interested parties would organize separate, specialized meetings or individual consultations and clarify what needs to be done. We were using whiteboards to communicate ideas and concepts during the meetings. All the drawings were photographed and shared on Jira for later reference.

Competitive Research

Image 13: Popular taxi apps for Android

The team did the initial research of the competing products. It was a quick way to obtain the common knowledge about the subject matter. We had studied the competition with the Project Manager and made some conclusions, but did not have the time to make formal documents about our findings.

The most popular taxi apps shared common patterns, like swipe to confirm payments and maps to specify locations. Some of the apps were obviously a part of white label product suites, which was obvious with taxi companies that didn’t invest into custom branding. But none of those products offered the possibility to automatically generate ride receipts, let alone doing so for a predefined period of time or a custom time span.

Exploration and Inspiration

Image 14: Night, city and taxi: stock images, web and image search

Initially, I was asking my colleague a lot of questions, because I had jumped into the project and needed to understand what we are building. We did not compete with Uber, as I originally thought. On the contrary - we aimed to support the regular taxi companies and their customers, especially business travelers.

I started researching online to learn more about everything and anything related to the taxi companies and applications. I needed to increase my knowledge on this topic. At some point I was required to deliver the dark UI, logo and branding. Before attempting to create a single branding element, I explored what’s out there and how to compete with it. Identifying the right inspiration in the ocean of information required time, experience and expertise.

The Product

Under did not compete with Uber. It was a white label application suite that made business easier for taxi companies and their customers in a niche market. It provided all the necessary documentation for tax exemption. Business users needed to refund travel expenses; companies needed the documentation.

A Minimum Viable Product (MVP) was planned for the first release, to reduce time to market. Passengers needed to hail a taxi and pay a ride, and it turned out the concept would not work without a mobile app for drivers. Two mobile apps and the Dispatcher web app had to be developed for the first release.

The Dispatcher app needed administration, so in terms of design, there were differences between permission levels. Design had to cover market differences, too. In Serbia, everyone uses 4-digit taxi ID numbers to identify vehicles. In Germany, people use license plate numbers for the same purpose.

The Process

Agile methodology is incredible, because it is fast and does not waste any time on philosophy. You can focus on finding a solution to the problem in the current context with the knowledge at hand.

We were trying to find solutions as fast as possible and deliver results as soon as possible. The MVP was the key concept of Agile methodology that has helped us in making decisions countless times. In order to support the process and the team, the design procedure had to be very similar to Lean UX: absorb the requirements, understand the motivations behind them, redefine the problem if necessary, choose viable solutions, design details, evaluate designs, repeat.

The minimal documentation concept was taken to extreme here. It was little to no documentation for the whole team, but only verbal communication for the design team. We had separate consultations with PM on the go all the time.

The Project

We were respecting the characteristics of the Agile process, held regular Scrum meetings, and improved our products in iterative cycles. Since this was an in-house project, there were no outside requirements. We were constantly making internal decisions about functionalities. But it also meant there was no funding. We were running on a shoestring budget with tight deadlines.

There was no time to step back and look at the whole from a birds-eye view, but I still tried doing so with the design of the suite as much as possible.

Agile can feel chaotic when there’s no philosophy and no visible strategy involved. Sometimes you need to stop, think for a while and come up with a strategy. Decisions you make beforehand can serve you as a guide in making future decisions. This applies to design as well as to all other disciplines: architecture, development, agriculture and everything else.

Sometimes we need to be pragmatic in design the same way we are pragmatic in real life, civil engineering or software development. After all, the most beautiful cities in the world were built on the riverbanks or on the seashores. We need the infrastructure that supports us in order to to build something useful. Whether we will build something beautiful along the way is the matter of personal initiative, team effort, circumstances and coincidence.

I started designing a software based on the dark map theme because it was practical at the time. I didn’t have to copy the colors or mimic the style of the map. I needed to make a brand that is in harmony with the infrastructure.

I had no idea that I would create one of my better designs while struggling with short deadlines and limited possibilities. I only tried to do my best in the given situation, at all levels and in all areas of my engagement in the project.