Summary

Brief
- To design a simpler way for those with a Business Booker (Premier Inn's B2B tool) account to apply for a Business Account card (Premier Inn's credit card)

For who
- Premier Inn

Things I learnt/improved on
- This required a lot of presenting and communicating between internal/external stakeholders and a range of positions, I greatly improved in this as the project went on
- My designs were heavily reliant on what our developers were able to do and so this allowed me to understand what our back end was capable of
- This was quite a technical project and gave me a deeper insight into development

Research

Requirements gathering

To understand the brief given to me fully, I arranged a requirements gathering session with the Head of B2B, our Product Owner, and a few other stakeholders. From this I was able to define all stakeholders involved in the project, both internal and external to the company, and know what results were expected from it - an easier way to apply for our Business Account cards that would boost application rates.

User flow

I then ran through the application process to understand what it was like to complete for a user. It was long winded and overwhelming. It seemed as if the questions were unending. During this, I created a user flow and noted all pieces of information asked of the user.

Field study and interviews

We work with a company called Worldline who are an e-payment service that allow us to run our credit card platform. All applications go through them. I took a trip up to their office to speak to their staff and see what they have to go through when handling these applications. They're split into three touch points. Firstly, someone reviews the application once it's sent in and decides whether they need any more information. There is someone else who calls applicants who haven't registered after their application was successful as it's possible they may need help in completing their registration. And a final team who review applications which have been flagged as possible fraud to request more information.

While here, I probed to understand what their roles were and how they worked. I also asked them their frustrations with the process and issues they saw repeatedly.

Here are a few things I learnt with a link to a document which contain all of my findings:

• One field asks for your company name which is checked against the Companies House, applications are often flagged up due to human error where the applicant hasn't included a space in the right place or has used 'and' instead of '&'. This slows the process down tremendously.
• We offer more types of payment than just Direct Debit (DD) despite only offering that option in the form, if the applicant wants to pay differently then they have to post in a note saying that they would like to. Again, very time consuming.
• There are several fields that no one seems to know why exist, they appear to be for marketing purposes but what we do with that information is unclear. If we don't use them then they only clutter the process.

Worldline research findings

Design

User flow

I looked first at designing the flow the user would have to take from first hearing about this card to the point of them clicking submit on the application form. We had different ideas of including notifications on the user's dashboard but decided to include a component on the payment section of the booking flow as this is when they are thinking about payment options. To not distract from their task of booking a hotel, we included a small amount of information to market the card and a tick box that could be selected to send an email with further details and a link to go to an application form.

Sketches

With the flow decided upon, the form could be designed. I began with initial sketches to try out ideas and communicate them with my PO to discuss the direction I was thinking of going.

Wireframes

Armed with the knowledge gained from visiting Worldline, I aimed to put those learnings into the designs. I assumed that we were able to pull in a lot of data from the user's Business Booker account and populate most of the fields so that applicants would mostly have to review the form rather than complete it. My second assumption was that we didn't really need to ask any of those marketing questions as I doubted we did anything with the answers. I designed the first iteration of the wireframes assuming they were both true before going into conversations to find out the answers so that I could better communicate this vision.

This would not only make the application process easier for the user but also reduce the likelihood of human error and reduce the risk of applications being flagged as incorrect. One instance of this being the case is that, as mentioned before, Worldline has to review many applications due to slight misspellings of company names. To register for Business Booker, you have to do a postcode lookup for your company which returns your company name exactly as it appears in the Companies House. This means that we could avoid any misspellings of company names being submitted.

Conversations

Developers

Using my designs, I approached our back end and middleware teams to understand what was possible and see how much information we have on the user and if we could pull that through into a form. Impressively, it came to light that we were able to populate the large majority of the fields from their profile. We even found that we obtain their company registration number through the postcode look up we do during registration and can provide that for the user - a piece of information that isn't likely known off the top of the user's head.

Head of B2B and our PO

The wireframe was looking more refined and had the backing of research and the developers, so I took it to the Head of B2B and our PO to get a few other questions answered. Firstly, I wanted to know about the marketing questions. After looking into it we realised that none were of any use and so we were able to remove these fields. Then, I raised a point found in the research at Worldline to do with payment options. We had companies in the public sector asking to pay by BACs as that was their policy and they weren't allowed to use DD. We only offer DD online and so have a roundabout method of getting the applicant to post us a note to request BACs. I wanted to see if we could offer BACs online. The response that came back is that we don't currently do this because we're only allowed a quota of companies that are allowed to pay this way. Upon further investigation it was found that this quota was only relevant for companies in the private sector and not the public, which was great as they were the ones who needed it. So this was approved too.

Worldline

One of our other aims with this project was to start bringing all design and development of our credit services in house as it currently sat with Worldline. They were to still manage applications and so for this application flow we knew we wanted to build the page ourselves but would still need to transfer the information over to them through the use of APIs.

This meant that we needed a meeting with the developers from Worldline so I could explain what was happening and discuss what development was necessary. Myself, our Head of B2B, PO, and several other stakeholders met at their office and I arranged our developers to call in from our office.

I presented my proposed designs to them while explaining choices made due to research findings and our developers explained how it was possible from our end. This presentation brought out a few ideas that Worldline had as well as new requirements.

Current state

The design was iterated upon based on discussions had with Worldline and then approved by our Head of B2B. We are currently waiting for the development of APIs to begin building this.