In October 2017 at Cleartrip, we decided to invest our efforts and energy in building a Progressive Web App for booking flights, hotels and local experiences. Why build yet another app when there’s a dedicated iOS, Android app and a fully functional website that caters the current needs without hiccups? In simple terms to leverage the state of the art web technologies to deliver enhanced experiences. For starters, service workers enable a progressive web app to load instantly, regardless of the network state. Slowly and steadily, Internet usage from mobile and tablet was surpassing desktop and it couldn’t have been a better timing to take the existing mobile experience to the next level.
Understand > Identify > Execute
At Cleartrip, we always start with the problem. We want to spend as much time as possible in understanding the problem. We believe that a problem well stated is half solved. In the context of this project, it was understanding why we were doing Progressive Web App in the first place. It was less about solving a problem and more about building an efficient base that can enhance the mobile experiences and set the stage for implementing future solutions.
The initial goal for designing the PWA was simple — bring it in par with the current features existing on other platforms and once we have everything to facilitate transactions and serving business needs, we would invest further to make it even more efficient and future-proof.
We started with taking an X-ray perspective which means looking through the complex widgets and visual styles of existing design, identifying the core content and functional pieces that make up the page and then finding the simplest equivalent for each to make it work. The approach that we took can be summed up in a three step process:
- Identify core functionality
- Make that functionality available using the simplest possible technology
The interesting outcome of implementing something as simple as this is that the more we used this process the less time it took.
Reinventing the wheel is the last thing that we would have wanted. Hence looking at how others have tackled similar problems was essential. We tried to find as many products with similar features/flows as we could. We also briefly discussed the pros and cons of the each of the approaches. Having done this analysis helped us make sure that we’re not reinventing the wheel. It also helped us identify common pitfalls or particularly complex areas to be aware of as we start designing.
Self evaluation is another part of competitive analysis. While designing an existing product, we looked inward. We evaluated what was working and what was not. Majority of the legacy features were not designed by us (Joy and I) so we sought out the explanations from the people involved at the time. It’s extremely important to know the constraints. History knowledge is extremely valuable but we also made sure that it didn’t limit our thinking. After all, history is a data-point.
Through simple and clear call to actions we made sure to differentiate one user's journey from other.
The search form was designed in a way that can be extended to different product journeys — trains, hotels etc as well.
We maintained our iconic Split Screen solution for round trip flight results. We used the good old HTML and CSS to achieve this layout.
We spent a lot of time thinking about enhancing the usability of the interface — not just in terms of using clear copy but also visually.
From the beginning, we made sure of having an icon system in place which would become a part of the full-fledged design system.
“Web design must mature and accept the developments of the past several years, abandon the exclusionary attitudes formed in the rough and tumble dotcom era, realize the coming future of a wide variety of devices and platforms, and separate semantic markup from presentation logic and behavior.” — Steven Champeon in a talk entitled Inclusive Web Design For the Future with Progressive Enhancement.
Progressive enhancement asks that designers start from the lowest common denominator — a well marked-up document — and build it up from there. Designing for the lowest common denominator doesn’t sound like a recipe for progress but this couldn’t be more wrong.
I struggled a lot to strike the balance between using the cutting edge technology while also extending the support to older browsers. We believed it was okay if a particular feature failed on older browser i.e., geo-location, service worker etc. As long as the core functionalities — booking tickets and hotels — were available, it would be fine. This is one of those areas that we still need to actively address.
Optimizing for speed
According to a Google study, 53% of users will abandon a site if it takes longer than 3 seconds to load. Once loaded, users expect them to be fast—no janky scrolling or slow-to-respond interfaces. We used approaches like loading shimmer experience to indicate that the page was still loading.
Design system increases efficiency. Having a design system in place from beginning helps in establishing a direction. Since we were putting the system from the scratch, we understood not only the what, but also why, behind it. At the end of the day, product is more than just a pile of reusable UI elements. It has a structure and meaning.
React has a steep learning curve. At Cleartrip, we designers prefer to write the front-end code. Since we decided to build PWA in React, I spent some time learning about it. I realized React had a steep learning curve but I am thankful that my engineer peers came to rescue every time I was stuck — especially Joy and Darpan (Thank you!).