A computer , laptop , tablet , phone and keyboard are sitting on a table.

CASE STUDY

RMB

Designing Rand Merchant Bank's website.

Move from a static pages to a more dynamically driven experience focused on the user

A white background with a few lines on it

Project Summary

The Rand Merchant Bank website was outdated and provided little value to clients or staff. This project required a complete website overhaul, from tech stack to design and objectives. We aimed to deliver a content delivery platform that enabled a better client experience, generated leads and delivered value to the business, not just a website.

Our objective was to build a user-centric platform that created value and improved engagement.

The team

This was executed by a small team of 3 people: 

 

  • Lead Designer (myself)
  • Lead Developer (who also assisted with UX)
  • Copywriter

 

My Role

I was the project lead responsible for all design work on the new RMB website. I worked closely with various stakeholders in conjunction with my team throughout the project. My deliverables included the following:
  • UX Design and Research
  • UI and Interaction Design
  • Information Architecture
  • Wire-framing
  • Prototyping 
  • User Acceptance Testing
  • Stakeholder and Project Management

Duration

July 2017 - May 2018

A bunch of screenshots of a website on a white background.

Steps taken

Design thinking was applied in this project, but this project can be summed up into these 6 steps.
Below is the story of each step in that process:

STEP 1

Business objectives

STEP 2

User
objectives

Step 3

Feature

requirements

STEP 4

Content

flows

STEP 5

Information

Architecture

STEP 6

Website

Design

STEP 1

Determining business objectives.

A black arrow pointing down on a white background.

Discovery

While there was a push to redesign the website from a marketing perspective, there were no clear objectives or goals put forward by business. I needed a better understanding of expectations from the broader business.

This was achieved by sending various stakeholders and business units a survey to better unpack their needs, frustrations and objectives.

Results

After consolidating all the feedback, I summarised the results into two key metrics that I could use as a brief for the project.
  1. Main objectives 
  2. Secondary objectives
When presenting the results from the above business objectives, I put the below quote into my presentation which helped me take stakeholders on a journey to the next step in my process...
A couple of sheets of paper with a lot of text on them.

“Clients do not care about business objectives   — it's user objectives that will drive behaviour.”

STEP 2

Who are our users,

what are their objectives?

A black arrow pointing down on a white background.

Personas

There was no clear picture of who we were talking to or user needs on the website. As gaining access to our C-Suite clients was not possible, I developed a persona worksheet and socialised it with stakeholders. These were then used to conducted interviews with staff members, deal makers and client coverage teams who had everyday exposure and access to clients.


Working with each area of the bank, we then created client personas. Between three and four personas were identified in each of the following business unit areas:

 

  1. Investment Banking 
  2. Corporate Banking 
  3. Global Markets
  4. Client coverage

 

For more information on my approach to creating personas, please refer to the following two published articles I wrote on personas:
Three sheets of paper with a lot of text on them on a white background.
There are many different types of people in this picture.

STEP 3

How should the website serve the user?

A black arrow pointing down on a white background.

Determining scope and feature requirements

Knowing who our users are (personas) and what they want (persona goals). I needed to understand why (the motivations) they want to achieve these goals. I could then determine how (feature) to best facilitate them using the website. 

I workshopped each of our persona's 'why' in accordance to their identified goals using the following formula:
As (persona), I want to (persona's goal), so that I (list of expected outcomes).
I then asked how we could facilitate each of these personas 'why’s (the outcomes from the above exercise) using the website.

The results was a tangible list of features that the website had to cater for, this exercise helped us to determine the project scope as well as inform our component requirements and provide the ingredients for the information architecture.

Identified feature list

  • Thought leader articles/Market commentary
  • Relevant contacts
  • Case studies/Awards/Deals
  • Research
  • Product information
  • Demonstrate capabilities
  • Client interviews (showcases)
  • Lead capture for further communication
  • Showcase events
  • Rates
  • FAQs
  • Document repository
  • NotificationsTools
  • Step by step guides
  • Comprehensive help section
  • Organograms of touchpoints
  • Careers

 

STEP 4

How do you marry business objectives, user objectives and a feature list?

A black arrow pointing down on a white background.

User journeys and content flows

User journey maps and flows were created. User goals and business objectives were then mapped onto each touchpoint, this helped to further define the project scope and ensure both user and business needs were met.


This process also helped to identify other potential opportunities that could be facilitated through the website.


To help us better understand the information architecture and how many personas each sections of the website would benefit, we developed a second set of journey maps beginning at different entry points. This further justified the various business cases for each section of the website.

Learnings

While we learnt a great deal about our users, business and various objectives that needed solving, a few other realisations were uncovered:
  • A user should never have to rely on the navigation to move through the website. 
  • A user has a number of possible journeys and those journeys were non-linear. 
  • The navigation should allows users to pivot quickly to a new objective. 
  • These learnings had a huge impact on our designed approach as well as how we engineered a system to exposed content that enabled richer user journeys.

STEP 5

Information architecture.

A black arrow pointing down on a white background.

Organising content

While we knew how to move users through content via our card system, we still needed to solve the content hierarchy and menu navigation. Our aim was to move to a more client-centric approach to content and services, instead of mirroring internal organisational structures. 

Collaboration via card sorting

This meant getting all relevant stakeholders together in a workshop exercise that involved arranging content and services collaboratively (via post-it notes) into our new proposed structure. 

Learnings

Whenever possible, get stakeholders together and facilitate collaboration with a focus on the end goal. Being the middleman via email is not a good tool for achieving consensus between stakeholders.

STEP 6

Wireframes, interface design and user acceptance testing.

A black arrow pointing down on a white background.

Wireframes

The user journey and research learnings informed my approach to wireframes. While referencing the identified feature list,  I developed a  wireframe kit of components that would form the building blocks of the website. This helped to plan and design a scalable, flexible front-end design system for the website.


I prototyped various wireframe layouts which were turned into clickable prototypes to test flows.

A bunch of different types of icons on a white background.
A set of cards with different images on them on a white background.

Cards enabled content discovery

Understanding that users should never have to rely on the navigation and that there were a number of possible journeys, required an extensive list of categories and tags were created. Pages and content was then be tagged and categorised with this metadata. 


Every page or piece of content was then also represented on a card in the UI. These cards would surface based on their relation to the existing page content via tagging or explicitly.

33

DESIGNED COMPONENTS

16

CARD VARIATIONS

24

BANNER VARIATIONS

1997

IMAGES GENERATED

Exploring various layout patterns via wireframes

A bunch of screenshots of a website on a gray background.

215

UNIQUE PAGES
(excluding deals and category pages)

204

CONTENT CATEGORIES
(page tags metadata)

9189

LINES OF CODE
( 16751 on the previous website)

226

CONTACTS LOADED
(contacts connected to every page)

Responsive UI design

Various page designs

A bunch of screenshots of a website on a white background.

User acceptance testing 

As development and content collection ran in conjunction with design, high fidelity prototypes with real content were coded and tested with users. I conducted several user interviews, testing the usability and understanding of the website. 

Post launch surveys

After the MVP was launched, we wanted to gather feedback from the existing users. We set up an online survey and asked people fill it out after using the website.

Insights gathered

  • Users expected to be able to click on icon labels on cards – icons were later linked to click throughs.
  • The 'Get in Touch' call to action area was overlooked by users, resulting in a redesigned 'Get in Touch' component.
  • Related content was not understood at first - this was fixed by adding section headings to area that housed related content.
  • Users expected to be able to download specific content directly from cards, this functionality was later catered for.

Project results and what I learnt.

A black arrow pointing down on a white background.

104%

INCREASED PAGE VIEWS

52%

MORE USERS VISITING

27%

INCREASED ENGAGEMENT

94

LEADS IN THE FIRST MONTH

What this project taught me

Research is a must

I would never have designed a website that was truly useful to both business and users without my research. The user survey revealed unexpected information and made it possible to adapt the product to users’ needs.


Personas are powerful 

Being aware of users’ needs, goals and objectives helped me to create a seamless, end-to-end experience.


Involve stakeholders 

Stakeholders know the business best, engaging with them allowed us to build an informed information architecture.


Challenges 

One of the challenges faced with this project was the lack of a content management system, as a result we were forced to build and architect our own light-weight internal CMS. The project was strongly taxonomy driven, as each piece of content was associated with multiple categories and contacts. This allowed us to serve related content as well as group content together on landing pages. Each landing page also had a lead capture form which connected leads to specific business contacts. We had to build systems to help facilitate these processes.