Successfully introducing User Experience Design (UXD) from scratch

So you have just landed on a project, and you are tasked with introducing the client to User Experience Design (UXD) and building a design system from scratch, you have autonomy on what needs to be done and have been brought in to help shape the vision for the project with your client. Sounds like a designer's dream right? 

Unfortunately, this is easier said than done. Many organisations are still in the early stages of having UXD as standard practice (or even at the very start like in this situation) and for our client, they were new to building bespoke software and delivering it in an agile format. When introducing different ways of working or new concepts this can be tricky for people to get their heads around.

So what are some of the things you can do in order to successfully upskill your client in UXD processes which will add value and have a lasting impact well after your engagement with them has finished?

Unfortunately, there isn’t one single answer to this question, it’s more of a combination of several things being done at different times throughout the project. Let’s run you through some of the things that worked well, the challenges we faced and our key learnings.

Client and project objectives - As a cross-functional team which Red Badger always advocates for, we were full of excitement landing on site of our new client, which was a traditional financial institution steeped in history. Our project was one of the first to use an agile delivery approach as part of an ambitious digital transformation programme.

We began the project with some key UXD objectives:

• Creating products which emphasise user-centred design and are simple to use
• Building a design system with an accompanying component library
• Introduction and upskilling of agile ways of working including UXD processes

What worked well

As mentioned earlier it wasn’t one single thing but a combination of several to make implementing UXD a success. Below is a high-level view of the four key areas we covered and will explain them in more detail.

1. Adapting the UXD process for our client  
2. Workshops 
3. Lunch ‘n’ learns
4. Building a design system

1. Adapting the UXD process for our client

While working with our client we realised some constraints, such a product owner (PO) who was time poor. To counteract this we needed to adapt the UXD process and come up with something which would allow our PO to understand the users and her team’s point of view but still allow her to make the final decision.

We developed a 4 stage process: 

1. Discovery workshop - Kick off with key stakeholders for group consensus and research before ideation
2. Design workshop - Workshop that combines ideation and design critique with idea prioritisation and helps teams collaborate and feel invested in the project.
3. User testing - To validate design decisions whilst gaining user insights and confidence before being released as part of the product 
4. Playback - A working session to ensure that design decisions align to business & user needs.

We also instilled transparency throughout this process, after every step we would share material in a format and open up for feedback from key stakeholders before moving forward. This really helped our clients feel part of the process and with them being able to see the outputs from each stage in the process.

2. Workshops

Throughout our engagement, we ran several workshops to help our client grasp the understanding of UXD, its value and how it forms part of the digital delivery process.

Design vision & principles

It was important to have a shared understanding between the badger team and our main stakeholders around the vision for great products and linked to this it’s vital to have a set of guiding principles that everyone can agree to.

We ran through what we felt were some good examples of design principles from Apple, Google Material and Medium so everyone could get a sense of what we wanted. We then ran through some best practices for principles before writing our own, voting and narrowing down to 4 concise principles we were all aligned on.

• Details are one click away - Understand our users need to make fast decisions
• Clear not cluttered - Guide focus with clear intuitive actions 
• Only the information I need - Reveal relevant information at the correct time and when useful
• Controlled customisation - Allow a sense of control and customisability without overcomplicating

Personas

A tool which is used widely across the digital industry, a fictitious character who represents your users. This was a new concept for our clients but we wanted them to grasp the idea of developing empathy with the audience for who you intend to use your product. Similarly to the vision session we gave some examples of personas we produced for other projects to get the juices flowing before making our own. 

Journey mapping

Another key tool is used by designers and for good reason. A customer journey map not only gives great direction for the product but often means all key stakeholders can look at a single picture and be in agreement.

The design vision & principles for the product, personas and some initial user research into current processes were summarised before kicking off this session. You can then highlight where the main pain points are for users in current systems, discuss what is needed for the future and map this out to give a full picture of what everyone has contributed towards.

Red Badger Design School

We run a one-day Bootcamp to give our non-design badgers an opportunity to learn more about UXD and become vocal and confident advocates of good design and user-centred processes. We also offer invites out to our clients who want to learn more about design.

 3. Lunch ‘n’ learns

As part of the engagement we wanted to share knowledge on different topics which would be useful for our client, this included a mix of UXD and tech-related subjects.

User research

As a key part of the UXD process we implemented for our client we could see it would be beneficial to open up a session to our wider stakeholders. The session covered:

• What user research is, what it’s important and what value we get out of it
• 20 different research methodologies based on Christian Rohrer’s  3-dimensional framework
• What research methods we had used with the client throughout the project to date and why
  
  

4. Building a design system

Another key aim for our project was to build a design system bespoke for our client which would be used for the products we were helping to build but then leave the foundation to be used for future products to be built after our engagement had finished. This was the first time our client had attempted to build out a design system which has key benefits not only for users but also from a tech perspective:

• Design patterns create consistency for users when learning a new product (in a complex industry). This helps onboarding of new team members
• Every reusable design pattern should have a corresponding reusable piece of code which exists in a component library
• Pieces of the system are reusable across multiple parts of a product and even across multiple products, again creating familiarity for users 

Challenges we faced

Of course, throughout our engagement it wasn’t all plain sailing, a few things we had to overcome.

Testing with a small pool of users

As we were building an internal tool it meant we had access to all of our users (designers' dream), the only downside was that we only had 21 to test which is a very small number. We had to be clever and you can read in more depth how we avoided testing bias. 

Agile project working within waterfall

Being a small part of agile working within a larger waterfall programme we did at certain points get blocked by other teams in the business, we had to be honest and clear about the implications and how it could affect delivery which our client was very appreciative.

Moving from in-person to full remote

Our engagement kicked off about 2 months before the coronavirus pandemic hit, meaning we had to adapt to fully remote working with our client. This was very tricky at first, with many meetings overrunning and communication getting muddied. We had to change certain UXD sessions like wireframing, sketching and shifting to using Invision’s freehand tool. Eventually, we were able to both get on the same page around expectations from each other to lead to a successful fully remote working partnership.

Key learnings

I often think don’t worry about the mistakes you made but be grateful for the lessons learnt along the way. We had a few for sure and are now ready when we face similar challenges again in the future.

Be patient when UXD is a new concept

When you are working with an organisation which hasn't been exposed to UXD it will take time, probably longer than you think it should for them to grasp the concept, you may have to explain things several times or in different ways so a full understanding is made. Keep going and one day it just seems to click for people! 

Getting people involved in UXD

We found involving stakeholders in the process really helped increase understanding and improve learning around UXD, such as inviting team members as observers to user testing sessions, including everyone from the Product Owner, BA’s, and engineers to QAs.

Put yourself in their shoes and make it fun

Getting to know who you're working with takes time, even if you haven’t heard of Bruce Tuckman's Forming, Storming, Norming, and Performing model you will have almost definitely experienced it somewhere. It can be painful but little things like team lunches, coffees, honest conversations with each other when it's not going well and fun remote activities all help towards morale and a high-performing team.