跳到主要內容

How we designed Booking.com for Business

How we designed Booking.com for Business

看最完整的內容請前往 http://blog.booking.com

Originally posted by in http://blog.booking.com
It’s no secret that Booking.com has a strong data-driven culture. We validate our work through A/B experimentation, allowing millions of customers to have their say in what works best. But quantitative research is not our answer to everything; we adjust our toolset to the problem at hand.
When we set out to build Booking.com for Business, it immediately felt like we were in a startup. Suddenly, the wealth of experimentation data at our disposal wasn’t enough to start building the application for businesses. To kick-off the design work, we needed to know more about our business users’ needs, motivations, and current frustrations. We needed to get out of the building and talk to them.

Initial research

We performed a series of user interviews in several countries with a significant share of business travel. We met with business travellers of all types (from interns to CEOs), along with the people who organise the business trips for them.
We learned that business users have unique set of needs. Booking a holiday can be a fun pastime on its own, but booking a business trip is part of a job—it needs to be as efficient as possible. There’s also more to business travel than making the booking itself. Companies need an overview of who is going where and how budgets are spent. Existing business travel solutions either don’t satisfy such needs, or they’re expensive and complex.
These and many other insights became the foundation for our work. They were synthesized into a set of user personas that shaped the design of the product as we went on.



Product vision

Armed with knowledge about potential users, we started brainstorming. Our aim was to create a vision of the product that would help our personas accomplish their goals. The outcome of these brainstorms was a list of high-level requirements that were later visualised as a set of wireframes. This tangible representation of our ideas enabled us to have fruitful conversations with stakeholders. The wireframes were high-level enough that we could temporarily set aside details of technical implementation and visual design, but also detailed enough to convey the purpose of each screen.



Minimal viable product (MVP)

The product vision was exciting, but it was just a hypothesis. We didn’t want to spend months implementing something ultimately not useful for customers, and not beneficial to our business. It was important to get the product out there as soon as possible, and to start learning from real world usage. We knew that we already had a great product—Booking.com itself—and we could build on its strengths. With this in mind, we defined the minimal scope that would be sufficient to validate our ideas, and started mapping out the user journey.


Filling the user journey with designs felt like finishing a puzzle. As we progressed, we could see how complete the whole picture was from the design perspective.
However, soon after we started implementation, we noticed a problem. Separate design mockups didn’t provide a true feeling of the user experience. They were static. It wasn’t always clear how the application would respond to user actions, and how one page would transition into another. We found ourselves figuring out these details along the way.
It was also important to get user feedback on design decisions we had made so far. Unfortunately, the actual product was still at the early stage of development, and putting mockups in front of users gave us limited feedback.

Prototype

As a response to these issues, we created an interactive prototype that simulated the end-to-end user flow. For example, it was possible to land on the product page, go through the sign-up process, view transactional emails, experience key application features, sign-out, and sign back in again. In this way, we solved two problems at once: we had created a tool that would better guide product development and procure high-quality user feedback.
We kept it lean and didn’t spend much time creating the prototype. We simply placed mockups in HTML files and connected them with hyperlinks. In-page interactions were triggered by bits of basic Javascript code that showed images of various UI states on click. For example, when the user clicked on an area of the mockup that had a button, the image changed simulating interface response.


Some design solutions that previously looked good as static mockups didn’t work so well when presented in the dynamic prototype. Acknowledging this helped us to fix design issues before they reached the product. Participants in user testing sessions were also more engaged with the prototype because it felt like a real product.
But prototypes are not without limitations. It’s hard to do full-blown usability tests with them. They may look real, but not every possible scenario is supported, so facilitators need to carefully steer participants. Maintaining the prototype also becomes tedious over time. We tried to make it easier by separating reusable parts like header, footer, navigation, etc. into include files. We accomplished this by using Jekyll, a static website generator.


The good news is that we didn’t have to rely solely on the prototype for long. The product quickly took shape and it soon became possible to put the real thing in front of users.

User feedback

After the product reached the MVP state, it became easier to get user feedback. Although the product wasn’t yet ready to be publicly announced, we were able to start gathering usage data and feedback from early adopters. We also continued usability testing, because the usage data told us what was happening, but often left us wondering why.


Even with the working product at our disposal, we continued using prototypes to fill the gaps during usability tests. We seamlessly integrated feature prototypes into the live product and switched them on specifically for usability session participants. This helped us to establish whether mocked-up ideas were worth implementing, and also to test parts of the application that were still in development.
Usability labs were not our only test environment. We visited company offices and observed how the product was performing in the real world. These office visits were highly valuable, providing us with insight from observation of users in their natural environment. We had a chance to see what tools they used, what workarounds they developed, and how our product would fit their work process. This was absolute gold. Some things that performed well in the lab set-up, failed during office visits.
We saw that our users were working in a very busy environment and were constantly distracted. The time they spent making a decision was very short. Plus, they were sceptical about introducing new tools into their work. All this posed a particular challenge for a crucial step in the user journey: the product page. Our users needed tangible proof that the product would do as it promised, and that it was reliable. They wanted to explore the product before making any commitments.

Product page

The research findings informed new product page designs. But we needed confirmation that they would actually solve the problems we had observed. We opted for remote surveys as a method to gather feedback quickly and on a large scale. This enabled us to cover several markets and bring a quantitative component into the research.
Survey participants were presented with various versions of the page and were asked to click and comment on page elements that stood out to them. Afterwards they were asked a series of questions that helped us gauge how well they understood our offering, and how likely they were to sign-up.
It took us a few survey iterations to arrive at a version that proved to work well for our users. Had we gone with one of the new designs without testing, we would have ended-up with a sub-optimal page upon product launch.
Now that we had the fully-tested user journey in place, we could reveal the product to the world.



Final thoughts

Fast forward to today. The product is up and running. We can now make decisions through A/B experimentation as there is an established base and a sufficient number of users that continues to grow. If we look back on the process that brought us here, this is what comes to mind:
  • In an environment of uncertainty, it was important to remain open to change. We had to think creatively not just about the product itself, but also about how to get there.
  • We were focused on the user from day one and all the way through. Even when we didn’t yet have the complete product, we used the prototype to get user feedback.
  • By combining quantitative and qualitative research methods, we got the best of both worlds. This was and will remain our recipe to continuously improve the user experience.

這個網誌中的熱門文章

COSCUP 2025 BoF / Hacking Corners 參與辦法及使用規則

你想在 COSCUP 現場發起一場自由討論、技術分享,或是臨時揪團寫 code 嗎?COSCUP 在會場安排了 BoF(Birds of a Feather)與 Hacking Corner 空間,鼓勵參與者除了聽議程,也能有更多樣的交流機會。以下說明本屆參與辦法與使用規則。 Want to initiate a spontaneous discussion, technical sharing, or impromptu code sprint at COSCUP? As always, COSCUP offers BoF (Birds of a Feather) and Hacking Corner spaces at the venue to encourage participants to engage beyond just attending sessions. Below are the participation guidelines and usage rules for these spaces. (English below) 1. 什麼是 BoF?和議程有什麼不一樣? BoF(Birds of a Feather)是一種由與會社群或參與者自主發起的小型聚會,形式彈性、主題不限。不同於主議程由大會策劃與審核,BoF 鼓勵任何人針對特定議題自發討論、交流,強調「興趣導向」與「雙向參與」。 2. 如何舉辦 BoF? 今年大會提供 TR310-2 作為 BoF 場地,建議會前於 電子佈告欄 預約空間使用及宣傳曝光。亦請詳閱 注意事項 。 3. 如何參加 BoF? 事前在電子佈告欄的 揪團區 +1 也可在現場直接前往 BoF Room(TR310-2)門口查看最新告示,無需報名,自由進出與參與討論 4. 會場外也有 BoF! COSCUP 是各地開源社群難得一年一度聚在一起的機會,很多社群會利用大會兩天晚上,甚至大會前後一兩周的時間舉辦聚會!無論想舉辦或想參與,都可以隨時利用 電子佈告欄 宣傳或查詢。 5. 什麼是 Hacking Corner? Hacking Corner 是現場開放空間(過去稱為 Hacking Room),讓會眾可臨時揪團進行共創、開發、技術交流等非正式活動。每個位置可約容納 10 人,不需...

COSCUP Lightning Talks - 2025 ⚡️

COSCUP 2025 閃電秀 / Lightning talks Photo by COSCUP 2024 紀錄組 閃電秀是一個由多場超短時的議程發表構成的一個表演性質居多的活動,通常會被放在獨佔時段,所有會眾都會聚集到這個會議廳觀賞這齣表演,稱之為閃電秀 (Lightning Talks)。 今年的閃電秀將於 2025 Aug 10 週日的下午 16:15 - 17:00 在 RB105 議程軌開講。 本次閃電秀的參加規則如下: 每個講題 3 分鐘,時間一到就會立刻切掉您的畫面,並邀請觀眾拍手掌聲鼓勵。 歡迎將您想曝光的 Projects、Idea 或小議題在這裡跟大家分享! 應遵守 COSCUP 的 CoC 規則 的原則之下進行發表演說,主持人有權基於本規則的判斷將不適合的發表暫停,並向大家說明理由。 需要再時限內完成報名 敬請自備筆電(和 HDMI 轉接器)上台 需要提早一場議程 (在結束前) 到 Main Hall (RB105) 報到 沒有限制發表語言,但建議可以使用英文或中文,大部分的現場觀眾能夠識別這兩種語言 *所有時區皆為 UTC+8 Lightning Talks is an event featuring multiple short speeches or presentations, typically held within an exclusive time slot. All attendees gather in the main hall to watch the show. This year, the Lightning talks is on Aug 10th from 16:15 - 17:00 (UCT+8) at Room RB105! Each talk is limited to 3 minutes. Once the time is up, your screen will be cut off immediately, and the audience will be invited to applaud and show encouragement. You're welcome to share any projects, ideas, or small topics you...

參與者活動攻略

參與者活動攻略 COSCUP 活動這麼多,不知道該從何下手嗎?讓本篇攻略依據情景帶你玩一遍 COSCUP 的所有活動吧! 平常情況下,你可以…… ➡️ 你可以聽議程,聽更多更多的議程,以及……總召論壇! 總召論壇 時間:8/10 15:00~16:00 地點:RB 105 我們召喚了幾年前的總召們一起聊聊 COSCUP 過去現在未來的改變,如果你好奇過去的 COSCUP 長什麼樣子,未來的 COSCUP 又該何去何從,絕對不能錯過總召論壇! ➡️ 聽完議程及論壇腰痠背痛,那就要去按摩小站馬殺雞一下 按摩小站 時間:8/9~8/10 10:00~16:00 地點:TR 413-2 ➡️ 身心舒緩後,口也渴了,這時候需要一杯氮氣咖啡 氮氣咖啡攤位 時間:8/9 9:00~16:30, 8/10 9:00~15:30 地點:TR 1F 川堂 ➡️ 手裡一杯咖啡,需要跟人聊聊天,BoF 是你絕佳的好去處 BoF 時間:8/9~8/10 10:00~16:00 地點:TR 310-2 ➡️ 在 BoF 站累了,需要休息,來去 Hacker Corner 休息吧 Hacker Corner 時間:8/9~8/10 10:00~16:00 地點:TR 309 及 TR 409 教室外走廊 ➡️ 充電足夠了,一定需要好好玩一番,可以跟著朋友們一起去社群攤位玩大地遊戲 大地遊戲 時間:8/9~8/10 10:00~16:00 地點:整個 COSCUP 會場 ➡️ 最後帶著你的大地遊戲戰利品去拍張形象照吧!來記錄下精彩的一天 形象照 時間:8/9~8/10 10:00~16:00 地點:TR 413-1 如果你是小啄的粉絲…… ➡️ 今年,我們為小啄準備了一面牆的成長照,還做了啄 Bug 之神的小神壇,歡迎解不了 Bug 的朋友一起許願參拜一下。 另外,我們在同一空間的旁邊還有 COSCUP 許願天燈的小板子跟 COSCUP 二十週年回顧,走過路過別錯過。 小啄成長史、COSCUP 二十週年回顧、許願天燈、小啄神壇 時間:8/9~8/10 10:00~16:00 地點:RB 105 1F 大廳 如果你有小孩…… ➡️ 難得的假日,你需要托育服務!讓自己真正放鬆,小孩大人都玩得開心 托育服務 時間:8/9  09:00~17:00, 8/10 09:00~15:30 地點:TR ...