跳到主要內容

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 2023 徵稿辦法 / COSCUP 2023 Call for Proposals

今年 COSCUP 一如往常,徵求各式各樣不同的 Open Source 相關稿件。請於 5 月 23 日 (UTC-12) 前投稿,或可參考本頁下方各議程軌資訊。 請注意, 每場議程長度預設為 30 分鐘 , 惟指定議程軌開放其他議程長度進行選擇 ,會在報名表單第二頁進行填寫,報名表單第一頁的提交型態中,請選擇預設值。 為了追求與全球社群更良好地溝通, 今年所有選中的議程都必須提供英文版的資訊 。一旦您的議程入選,我們會請您提供議程資訊的英文版翻譯。您仍可以自己偏好的語言演講或撰寫 CfP 稿件。 提醒您,COSCUP 是一個倡導開放的研討會,所有演講將錄影並以創用 YouTube CC 姓名標示-相同方式分享 4.0 釋出。如果您的演講有任何不能錄影或不願以此條款釋出的狀況,請務必於投稿表單上註明。 We are looking for talks in several open-source related areas, please submit your proposal before May 23th, 2023 (AoE, Anywhere on Earth, UTC-12) . After the review process from the coordinators, we will publish the full programme in early June. Please note that the length of each agenda is preset to 30 minutes, only the specific tracks are open to other agenda lengths for selection, which will be filled in on the second page of the registration form. In the submission type on the first page of the submission form, please select the default value (30 mins) . For better communication with the glob

2022!前夜派對!Open source and wine!Welcome Party!

喝! 年會 前夜 的交流 派對 ,來與大會講者、社群同好一起喝酒聊天! Join the Party, have fun with the speakers and your beloved FLOSS community members! 會場有什麼? / What will we have at the party? 當日精選的 MIT 掌門精釀啤酒 (也有無酒精飲料) Beer ! For people who don't like alcohol, the bar also provides soft drinks. 下酒點心 Snacks 200 坪空中花園派對,可以直接看到台北 101!美景與美酒,絕配! Awesome view, believe me! Just check the photos from Google Maps. 最重要的是:與熱愛開源的大會講者與社群同好交流的最佳活動! Lots of FLOSS folks! 注意事項 / Note 會場食物為小零食,數量有限,建議吃過正餐再來! Please have your dinner before the party, we only prepare party appetizers. 低消為 $200 元。 The minimum order is NTD$200. 不用報名,自由參加。 Please feel free to join Welcome Party, no matter what you come to COSCUP x KCD Taiwan 2022 or not. 贊助商請找 贊助組 領取酒券。 If you are the sponsor, please contact the Sponsorship Team for the free beer ticket. 如果你怕忘記參加活動,可以訂閱 COSCUP 活動電子報 ,不錯過最新活動訊息! Subscribe the COSCUP newspaper to receive important reminders and exciting activities. 時間地點 / When, Where 時

會眾新服務「療癒市集」結合紅酒瑜伽、冥想正念、按摩小站、氮氣咖啡 | Introducing the Healing Market with Yoga Wine, Meditations, Massage Station, Nitro Coffee

新 [English version below] 今年的 COSCUP x KCD 2022 Taiwan 嘗試推出新的會眾服務,希望在繁忙的平日還抽空在假日來參與活動時、能夠療癒一下心靈與身體的負擔,「 療癒市集 」希望能夠為你帶來不一樣的體驗! 由於部分課程需要 預先報名 ,如果你有意參與課程,請直接 寄信報名 ,並等候志工收件處理,感謝! 以下是相關的課程簡介。 紅酒瑜伽 照片來源:台南安平雅樂軒酒店 都市生活步調快,上班壓力大,周末總想找些紓壓的活動幫自己充飽電,用更好的狀態去迎接下個挑戰。而說到現在最新穎,時尚的選擇那就不能不提風靡歐美的「紅酒瑜珈」。現在不用出國,在 COSCUP 也可以體驗這種身心靈保養的運動。 課程中,老師也會指引學員在不同階段品嘗手中的葡萄酒,感受這支紅酒在不同醒酒階段的各種風味,細細品嚐它的層次與韻味。酒精也同時能夠增加血液循環,讓身體發熱,達到肌肉暖身,類似熱瑜珈的運動效果! 紅酒瑜珈是什麼? 於 2017 年誕生於紐約,紅酒瑜珈是把紅酒帶進瑜珈練習的一種課程。在瑜珈練習的過程中,學員們手上各有一杯紅酒。老師帶領著學員練習瑜珈姿勢,並加入酒杯動作來增加難度與運動量。比如說,手握紅酒杯進行戰士三式(Warrior III),為了不讓液體撒出來,其實比起沒有道具輔助的瑜珈需要多一點肌耐力,所以可以達到更大的脂肪燃燒跟運動效果。 課程須知 每一課程時長為一個小時,費用 $470元/人,每一堂最多 12 人。 講座內容包含:活動包含約 45 分鐘的紅酒瑜珈活動,及約 15 分鐘的講解,課程會提供酒杯,若損壞葡萄酒杯,則每只費用 $250。 需自備:瑜伽墊、水壺、毛巾等個人用品。 ★ 由於課程需要預先報名,如果你有意參與此課程,請參閱 課程時間表 並直接 寄信報名 、等候志工收件處理,感謝! 冥想正念 我們都渴望獲得內心的平靜,尤其在現在這個快速、忙碌更迭的時代,在這個無時無刻都在面對比較、落後焦慮的世代。透過冥想與正念,你會更加理解你自己,你也會更加理解你的周遭一切,而點滴的時光之間,再次放下自我,又擁抱自我。 課程須知 每一課程時長為一個小時,費用 $350元/人,每一堂最多 10 人(未滿 5 人不開課)。 講座內容包含:冥想正念概念介紹、正念心理