Author: Michael Saravia

One source of truth for guidelines and documentation

The problem

At Booking.com, our design community is over 200+ designers that work alongside in creating a seamless experience for all users from guests booking their upcoming accommodation, to properties uploading their availabilities in their calendar from desktop to mobile or an app. So how do we make sure that all designers don’t constantly reinvent layouts and interactions across platforms and departments?

My design thinking

Collaborating with one of our principal designers, for several months we worked together in writing down multiple documentations around guidelines for building partner facing products. I achieved this by doing research with already documentations created out in the outer webs. Listing all common topics that needed to be covered, did an audit of our extranet and added missing topics that separated us from other businesses guidelines.

Wrote first drafts on all topics, did a community design feedback session to revue if our communication was clear and easy to use. Collected all the feedback shared and did iterations to evolve thanks to their feedback and input. Once the drafts were covering all scenarios, we collaborated with our internal copywriters to sign off on our grammar and spelling.

The solution

I took the task to compile all documentation around guidelines for building partner facing products. To help the designers working at Booking.com, to reference in best practices, guidelines, localisation and more. All this was compiled into an internal website that anyone at the company could access and use as reference.

Who would this impacted

This helped all graphic, web and user experience designers. It also was picked up by front end developers across our global offices.

My contribution to the project

Building this solid foundation of one source of truth for all creative departments turned out to help all designers building a unified experience across all pages and devices. This also became a helpful tool for developers to reference and create an alternative version for themselves to reference in best practices of coding.

THE TOPIC

At Booking.com, as we strive to give partners (property owners) a frictionless experience, we originally had our extranet setup to only support one account (user) per property. From previous research we knew there was an interest in having the possibility of creating accounts and controlling their permissions, both from a partner and company perspective.

THE PROBLEM

So why did partners want to have multiple accounts? According to my research and analysis, the limitation of single account was that properties had to share their username and password with their whole team. Allowing for everyone to have full access across the property account on the extranet was risky. There was also the fact that on each login attempt, there was a 2FA security check which would be sending a temporary code to the account owner’s phone and they could have been absence for many reasons like not at the office or out of their working hours. Then the login process was a painful blocker for their business.

If passwords were shared between employees, if one of their employees would quiet or get fired. The password would require to be changed immediately and shared again with the rest of the team. If there was a malicious current or ex-employee wanting to change details on the property account, there wouldn’t be any way of tracking who did the changes.

MY DESIGN THINKING

I needed to understand more detailed requirements why partners wanted to do with the capability of having multiple accounts connected to their properties. I decided the best way was via a qualitative user interview research. The interviews help me know what actions users were performing on their extranet accounts. For example, in order to be able to manage the accounts themselves, including restricting access were important features for them.

Through a survey, I wanted to understand who was interested at a property type next. If the features they were most interested changed between property size, team size and type. As expected from the results, the larger properties were more interest in the possibilities of having these accounts and permissions. But the most important features was still about tracking user activity, the ability to manage accounts themselves and choosing permissions for each user.

THE SOLUTION

I created a user flow and design for the new extranet feature where partners would create and manage additional user accounts and tailor the permissions for each user individually. I believed this change of allowing properties to manage more then one account and control their permissions was going to be beneficial because it would allow partners to manage accounts autonomously. It would increase security, as partners would not need to share anymore one username/ID and password among members of their team. It would also be easier for us at B.com to tailor a more personalised interaction with them, by using our role options provided. So when they visit the extranet or receive communication from B.com it would be more relevant.

THE IMPACT

This new feature was going to be optimised to use for individual properties. Depending on the success and perceived value for our partners, this would possibly had been further improved with more functionality and the ability to manage our more complex level of properties (group accounts).

The product was launched to all listings worldwide, with one exception being the group accounts. The initial feature is optimised for individual listings. To create or manage group user accounts, the procedure still remains broadly unchanged and B.com needs to be contacted for assistance because of its large complex scale.

MY CONTRIBUTION

Because of my effort in creating a frictionless experience for partners to create and maintain their work more efficiently and improve their security. It was a huge improvement for them all. Our customer service tickets went down in creating multiple accounts, it also reduced submissions of partners having lost their password and someone login into their accounts without their awareness. Partners felt more secured and could monitor any discrepancy themselves.