Design at Skyscanner
By Chris Roy
Skyscanner in a nutshell
For those of you who have just stumbled across this post without any idea of what Skyscanner is and what we do, we are a travel company. We search flights, hotels and car hire companies so that our users can choose the deals that suit them best. Having been around since 2003, we now have more than 500 employees across 9 offices and our website and apps get an average of 30 million visitors each month.
My past 2 years
As April 2015 approaches, so does my 2 year Skysc-anniversary. Since I started I’ve seen many positive changes, within the design team and the company as a whole, which I’d like to share in this post. Before joining Skyscanner I worked in various in-house design positions, and have experienced the good, the bad and the ugly of office cultures and company structures. On joining the company, I was hired as a Senior UX Designer and my role has since evolved into Senior Designer (Generalist) for our Hotels product. Essentially, my role has progressed from being specifically focused on user-centered design, creating flows and wireframes, to also include elements of engineering, visual design and interaction across both apps and web, meaning that ideas can now be taken from paper to prototype much more quickly with less dependency on developers.
The Fence
Joining Skyscanner was refreshing. Working within a UX Design team of around 5 people, it was easy to bounce ideas off other designers. However, it struck me was that there was a fence. We are all familiar with the idea of the designer/developer fence, but I found that there was a similar barrier between the two design teams in the company at the time: UX Design and Marketing Design. Not to say that we didn’t get on, but our roles and our day-to-day work did not seem to cross paths as much as you might expect.
UX was practiced as one discipline by one team across multiple projects and, depending on the need of that project, some of them would get handed over to the Marketing Design team to apply visual design styling. Crudely put, one team would create boxes and arrows, and the other would colour them in. Like others in the UX team I’d come from a multidisciplinary background, but this two-team structure meant that I had to enforce creative restraint, knowing that there was a separate team that would pick up that side of things. At first it felt awkward, but as with all things, I just got used to it.
Rocks and sticks
In those days of split teams, work was done using a plethora of tools. UX Designers may have used Photoshop to hack up snapshots of live site screenshots, Axure to create interactive prototypes for web and native apps, and sometimes — the now laid to rest — Fireworks. Our principal UX Designer even made use of PowerPoint for flows and interactions. Designs in these various formats would then be passed over the fence to the Marketing Designers, who would apply visual styling in the likes of Photoshop or Illustrator before later passing across to the engineers to implement. While the tools worked, the completed designs were somewhat removed from the final medium of the web or native apps.
Designers for hire
As well as the two design teams being split from each other, both physically and organisationally, we were also split between various projects. UX Designers worked on each of the product verticals (Flights, Hotels and Car Hire), as well as picking up some cross-business projects. Meanwhile the Marketing Designers worked on Marketing, PR and Social projects, and picked up the visual design for any product projects that appeared over the aforementioned fence. In both cases however, design was very much a service to the rest of the company, and therefore fought over by various product managers and team leads.
Fast forward to today
Back in the summer of 2014, the company made a huge shift from the scattered organisation of teams and tooling, and moved everyone across to the “Squad” model which was first introduced by Spotify in 2012. In short, “squadification” means that we work in small, self-sufficient teams, each containing a Product Owner, Project Manager and engineering, test and design resources. In essence, each team should be able to create and build new features or products and deliver these with minimal or no dependency on any other squad (depending on the needs and the scale of the piece of work).
For designers, this means that we were no longer providing an external service to a separate team of developers. Instead, each designer is now an integral, decision-making member of a squad. Instead of sitting alongside our design peers, we now sit beside other squad members. These changes have smashed through the designer/developer fence; each squad has stand-ups each morning, and designers, engineers and other squad members collaborate throughout the day to get work done.
We still have a split of Product and Marketing designers but now the Product designers, which have grown in numbers to allow at least one designer per tribe, have design autonomy to explore the visual design of their ideas. This is complimented by a weekly catch up across product teams to ensure we are aligned in our styles and allows us to feedback on others work. We also have a bi-monthly catch up with the Marketing design team to get the latest on any brand updates or campaigns, which helps keep things aligned across the broader scope of design.
Swapping rocks & sticks for blowtorches & gasoline
Now with a 16-strong design team, representing a wide mix of design skills and disciplines, we have begun to adopt new, more collaborative approaches to our work. One major shift — which began last year — was the move out of Photoshop and into the browser — a topic of much discussion in the industry today.
The result? We have found that by removing the level of abstraction that comes with static mockups, we have been able to progress and experiment with responsive implementations at a much greater pace. We now have designers in squads who are pushing code to the live site. An idea or improvement can go from paper to published live in a matter of days, because the designer has full ownership of that cycle (obviously working alongside product managers and engineers). Working in code is also a great way to collaborate with designers via Git. We can all work on our own design components and, once ready, push them up for other designers to contribute to and use.
In a conference last year, Luke Wroblowski stated that we have a lot to learn, but even more-so, we have a lot to unlearn! Mentally and visually, thinking of our websites and applications as page views is no longer a sustainable way of thinking. We need to think smaller — to design in terms of components and states and the relationship between these, in line with the data that is available.
We are a travel company, first and foremost, but we exist as a travel company that was built on data, so it is natural for us that we design with data in mind. Whether we’re trying to represent the complexities of a flight itinerary, or a page of hotel search results, designers must consider all the possible data states and relationships, and how to deal with data excesses and scarcity. Designing in the browser has provided new opportunities (and challenges) in this area, and we now have designers creating their own JSON files, playing with that data in their mockups, and working from live APIs to see how the interface and the experience interact with the data that is available.
This is a very different type of design to the one I initially started out in. It’s exciting and challenging at the same time and I would encourage designers to (if nothing else) play with code. In a response to a question posted on Tavern on the subject of “should designers learn how to code”, I used an example of a print designer creating their designs without ever having felt the textures of paper, or who was unfamiliar with the CMYK colour space. Sounds crazy doesn’t it!
Wrap up…
This article was intended to capture the phenomenal progress of the design team within Skyscanner and to discuss some of the things we have learned along the way. As my dad used to always say, “Learn by others’ mistakes”. If you recognise any of the problems with team structures, productivity barriers, design tools or workflows that I’ve described, now is the time to turn and change direction. We would be keen to hear any comments or feedback, or see how other design teams have approached similar topics.
This is also an article that we hope outlines and captures some of the great and exciting things that are happening here at Skyscanner, so if you are a designer who feels that a rewarding design career in the travel industry feels like the next step for you, please head on over to our job section to see our current vacancies.
