On the 22 of August 2024 I officially graduated from Shift Nudge, a UI design course by Matt Smith (MDS). Endorsed by people like Noah Levin, VP Design at Figma, and trusted by thousands of designers at top companies like Apple, Microsoft, and Intercom—it's the most complete resource available.

I managed to secure internal funding for this after I identified the untapped gap of UI design craft at Moonpig, that directly influences our NPS score (a long-term company OKR). After discussing it with design leadership and demonstrating my new abilities, it soon became our key growth area in the design team.

In total I successfully completed 49 lessons over 9 weeks, across fundamentals of Typography, Layout, and Colour, plus advanced topics of Style, Imagery, and Elements—covering patterns like navigation, user input, and settings pages.

Overall I spent around 120 hours on studying and design practice.

Identifying the opportunity

I used a variety of data-points to identify the gap in both my own skillset and that of the wider design team:

• NPS issues report. Our lead researcher delivers a monthly report on how our NPS is tracking, and there's a section on key issues. One of the top five issues we found were "General UX issues" which affected every part of the journey which I hypothesised to be something around general UI application.
• Design system support requests. We received frequent support requests that usually were equal parts misalignment in the design system, but also suboptimal application of the system and design fundamentals.
• Continuous discovery.  In weekly conversations with designers, I started to see and hear more frequently the desire to be "better at styling" our work.
• Research reports and Slack. Various research findings and Slack threads showed internal dissatisfaction with UI quality we could repeatably achieve.
• Design system analytics. I benchmarked a few designer files using plugins for adherance to our system and spacing scale. Results had high variance, indicating a harder time for engineers to build consistent, high quality UI.

Altogether this was enough for me to embark on the journey to improve not just our design capability, but also organisationally the UI quality we could deliver.

Teaching UI design

Design is finished if it reaches the customer.

I ran two Shift Nudge inspired workshops and design critiques to up skill the team, in order to seize an uplift in CSAT from high quality designs. In addition, I've been evaluating tooling to analyse designer usage of our design system to aid more responsible handoff to engineers.

I hope to inspire our team to one day take on the full Shift Nudge programme.

Work before Shift Nudge

Here's some previous work I've designed as a comparison.

2023: Social media posts

I released a course teaching Figma for complete beginners, and co-hosted a podcast. To support these efforts I created a variety of social media assets to post on Instagram, LinkedIn, and Twitter.

With some critique and guest posts from a visually strong designer, I took on her learnings and found that finessing typography, colour, and layout can significantly elevate the final result.

2018: Cycling app dashboard

During this time I was still focused on UX, at the expense of learning the fundamentals of UI design. While my user tests were strong on task success, I now appreciate there's a much deeper link between UX and UI.

I can see on this redesign I had a reasonable grasp of standard UI elements, the basics of alignment, and using things like scale and colour to set hierarchy. Now, I'd look at the following to improve this:

• Layout: simply taking care by using a clear grid, multiples of 4px spacing, and alignment of elements make it look professional.
• Colour: the brightness of the green makes it difficult to retain visual clarity in elements like buttons, and there's no supporting colours.
• Icons and imagery: I've used 5 different icon sizes, if you include the coffee cup, and I mix line and solid styles.
• Visual hierarchy: as there's only snippets of text, this can be looked at with visual hierarchy in mind. Typographical sizing, colour, and placement can be used set a clearer visual hierarchy.
• Empty states: the visual difference between rest and active days aren't clear. Effort spent on empty states, can subtly elevate the experience.
• Design direction: while there wasn't a strong design direction to start with, I'd recommend experimenting iteratively with the client here.

Measuring change

After speaking with our Product Analytics team and reviewing past work with Product Managers, I learned that it would take time before improvements in UI quality could be detected in performance metrics. Individual changes are often too small to register in isolation, so we rely on a mix of judgement, conviction, and triangulation. This means batching changes together to make them measurable in attribution studies or A/B tests, while also running regular “spot checks” with customers to ensure changes are understood and appreciated.

To build confidence in this model, I led a cross-platform CTA colour change initiative. By validating the change with user research and controlled experiments, we demonstrated a six-figure uplift in annual revenue. This created stronger organisational belief that even seemingly small UI improvements can compound to deliver significant business value, making future investment in design quality easier to justify.

Impact

Here's the highlights:

• Designer confidence, my business oriented OKR, increased by a collective 23.5 points; 117.5% of my target. I ran two workshops, with 14 participants across Product, Design, Brand, Marketing, Data, and Engineering.
• Visual appeal increased to 6.44 on a key touch point I designed for, up from 5.83, simply by adjusting colour. A 0.61 increase on a 7-point scale.
• High quality UI design is now a focus area for the design team for H1 of 2024/25, as set by our design leadership, now expanding out to H1 of 2025/26.

Summary and learnings

Shift Nudge taught me a whole new level of appreciation for the craft of UI design, and how it's intrinsically always linked to the UX. Over time I've matured and sought work that pushes me to grow, and solve design challenges to a world class standard.

Some of my favourite learnings from Shift Nudge:

• 🎨 Colour selection and modification: I found this the most difficult aspect, but I grew the most by understanding colour in depth. Not only was it around colour theory and creating balanced aesthetics, but the strategic element of interactive verus non-interactive elements.
• 📐 Layout and precision: my approach is typically precise and methodical, but I learned a whole new level of precision with my work completing the course. Social media posts are small enough that imperfections can be glossed over, but not so easy with interface design.
• 💅 Design direction: whether straddling the friendly-to-professional feel, or making something fun or feel more premium and luxurious, I have a deeper understanding of exploring, setting, and executing on a design direction. This helps me work more closely with brand.

For any designers reading: seriously, check it out! https://shiftnudge.com/.

at Residently • B2B • PropTech

During work on our B2B offering for property managers at Residently, it was clear that there was high friction when entering the Security Deposit and Holding deposit amounts. It was often rounded incorrectly when automated, users needed a calculator or spreadsheet to hand, or the amounts could be non-compliant.

In addition, the timeline here was tight—a couple of days to design 80% of the solution.

As an end-to-end design piece, I wanted to answer:

Can we improve input accuracy without sacrificing ownership of setting rental deposit amounts, in a low risk way?

Overview

First an overview of the roles I assumed, the skills I used, and the team involved.

Employer

• Residently

Roles

• Lead UX Designer

Skills and techniques

• Content Design
• Interaction Design
• Wireframing
• Figma high-fidelity prototyping
• Design Systems
• Usability testing
• Questionnaire

Team

Whilst my primary role was as a Lead UX Designer to oversee our 3 squads, for this piece of work I embedded myself into the squad. Each squad takes a Lean UX approach, to discover and design one "slice" of a feature per sprint, ready for the next one.

This squad contained:

• A Product Manager
• A Technical Lead
• 4 Engineers

From our Discovery and Design horizontal, I received support and critique from 2 other Designers and 2 other Product Managers during "Design Critique" sessions.

Understanding the problem

First, a brief overview of how the concepts are modelled in the system, helps to understand the complexities involved:

As for this specific case itself—the tenancies our partners were putting through our product, required four monetary amounts:

• the monthly rental value
• a security deposit
• a holding deposit
• total upfront rent

These amounts were used when tenants were invited to supply their details, pay their holding deposit, and displayed the first rental payment amount required before they could move in.

We previously calculated the latter two fields automatically for our partners, but we had frequent requests to our Engineering team to update or alter them. This was due to a few reasons:

• Different partners had different pro-rata calculations—for partial months you can calculate based off total annual rent divided by 365, or monthly rent divided by the number of days in that month.
• Some tenancies were calculated differently to the partner's "default"—for example one partner had branched to a new city and ran that portfolio differently, or a partial holding deposit had already been taken.
• The legal maximum security deposit could change depending on the rental value—it's 5 weeks rent for under £50k per annum, or 6 weeks if over.

Originally, this product issue was raised by one of our Product Managers. Data or evidence supporting this case came from our internal operations team. They kept a note of frequency of this request type, if it was due to mistakes, or due to rounding errors. It was high.

I had seen the spreadsheet myself, I'm in our #product-support Slack channel, and had fulfilled this request when I was a Tech Lead, so I'm confident this was a recurring high friction issue worth solving.

In short, there were no true one offs. It happens frequently!

Additionally as mentioned in the introduction, partners had free-form fields to which they could enter any amount—we build this as a first version. They often required a calculator or a spreadsheet to check and re-check the amounts.

Problem framing

This was not only a challenge of providing the functionality to eliminate the frequent requests, but also to win confidence in our calculations. This previously was not strong, due to the frequency of the issue.

Summarised as a How Might We:

How Might We give our partners confidence to accurately and swiftly calculate deposit amounts in the product, without sacrificing ownership?

Phrased as a hypothesis, it would be:

H1: a calculate button increases speed and confidence to fill forms with these fields.

and the null hypothesis:

H0: a calculate button does not increase speed or confidence filling forms with these fields.

Designing it

It's worth noting at this point in time, partners and agents could input any amount in the new tenancy flow in the product. As a first version, we wanted to provide unrestricted access.

Aligning everyone to the same page

Deposit amounts is integral to the rental journey, so I knew it would affect more than a single touch point. I did a User Journey map and workshopped that back to the team for input and correction.

The biggest value for me was making the error cases clear; in all the forms, total rental amount was required in order to calculate all the other deposit amounts.

In addition, I could ask for engineering input any initial ideas or constraints we might have when building this feature.

Why: this allows us to assess what flows this would affect, how the flows worked, and describe how we want it to work. It quickly gets everyone on the same page, and highlight any gaps, before beginning the ideation and prototyping phase.

In total there are 3 existing product flows that this feature affected, and involved 2 design languages: the recent B2B interface, and the older B2C interface.

Identifying a solution

As a starting point I like to refer to any ideas the Product Manager has. This helps me guide our thinking to the best solution. Initially we used a simple button next to the text field. I mocked this up, and jotted down some thoughts the partner might have.

Here's some of the ideas I experimented with, in collaboration with the Product Manager.

At this point, we found that it was difficult to visually communicate that:

• this singlular button fills in these two fields
• the rental amount is required to calculate both of them

This then iterated to what we had below, where visually both fields are related:

Above you can see that I wanted to integrate the button into the text field itself. My thinking was:

• It's available on MUI's text input component
• Date picker is an existing, similar, and successful UI pattern

In the end, this was the result of this stage and became the first iteration to go forward to validation.

Assessing technical constraints

Once I put together a static set of screens that described the solution, the edge cases, and I showcased it to our Tech Lead and Product Manager. I wanted to assess any deeper technical constraints we might have.

This was helpful as our Tech Lead helped to identify 2 extra cases I hadn't anticipated:

• The calculation process takes a while, but the field was still editable
• The calculation process failed, and we need to tell the user what happened

For these I could disable the field, and feedback to the user respectively.

Designing for the other design language

The tenant facing side of our product had a completely different langauge, and had a different set of UI components. This made it difficult to compose a flow together. In the interest of efficiency I had to create a set of pseudo-components to work with, and place them on top of screenshots.

This was okay since we were focusing most of our efforts on the partner side of the product, and resident facing work was occasional.

Validation

As part of the validation phase, I answered 3 areas:

• Overall usability—was this flow understandable, and easy to navigate?
• Icon or a word—is the icon enough, or would a word be clearer?
• Error cases—what's the clearest way to feedback and help fix errors?

Assessing overall usability

For this work I attempted to set up User Testing, as a quick way to get some general feedback and see if the flow was navigable.

Unfortunately our subscription came to an end and wasn't renewed earlier in the year. I tried setting up an ad-hoc test, but it would cost around £500 for this single test. I couldn't get the budget, and it would take a while to renew our subscription. Instead, I sought to test internally.

As part of internal testing I used 2 types of users:

• people in the product team who haven't worked on this feature
• our operations team who work closely with our partners, daily

In conclusion the results were successful. No one struggled with the flow, but I identified a few smaller issues. Some of the feedback quotes were:

"Why is it in a grey box? Is that necessary?"

"Would the word 'Calculate' be clearer maybe?"

"That looks like a date picker icon!"

These I sought to address in a few follow up, smaller tests.

Uncertainty in using an icon, versus the word

I created the two conditions we were thinking of, mocked them up, and shared them internally for feedback. Overall, we landed on an icon being consistent with the rest of the product, and more flexible when composing layouts in other parts of the system.

How to notify that rental amount is missing

When the rental amount was missing, we couldn't calculate any of the other fields. As part of validation I wanted to verify if:

• The rental amount field should error, since that's where we need to action it
• The security deposit field should error, since that's the field that needs something else

After internal testing to those who hadn't seen these screens, I found that highlighting the rental amount field could be disorienting and confusing. In addition, other forms may have these fields further apart, requiring a "scroll to" behaviour. Finally, it was less complex to build with the latter style.

Therefore, I accepted this as the pattern to use moving forward and absorbed it back into our Design System.

Post launch iteration

After validation we built and released this on the live system, and trialled it with a few partners before building and rolling out the other two flows.

One thing that was easy to change post-build, and was still an open question, was the feedback we had earlier.

"That looks like a date picker icon!"

After a quick look through the icon set we were using, mocking them up, and sharing them around internally, we were convinced we had picked the correct one. In addition, partners were not experiencing issues performing the task, so we left it as it was.

The final design

After all the iteration, and designing for all the edge cases, the final design looked and worked like this:

• Each field worked independently, and was sometimes used without the other, so the grey background was removed
• We couldn't agree on an alternative icon, and decided to "test in production" given it was easy to change
• Microcopy on the tooltip and error copy was finessed for each case

Outcomes

After this process, given the time constraints, this was enough for us to close off this feature for now and iterate properly later. After the entire MVP was delivered, I created a broader research strategy to validate the "design debt" we'd taken on from this and other pieces.

In total there were 3 main outcomes from this work, found through Hotjar analysis, partner helpdesk requests, and speaking with our Operations team:

• 0 requests to amend deposit amounts were raised since release
• 0 requests of "incorrect upfront amounts" were raised by partners or tenants
• Greatly improved speed to fill the form

Further work

Reflecting on it now, here's what I'd do differently if I could go back in time:

• Secure access to user testing tools before any big deadline—whilst I found workarounds for user research and validation, it was unfortunate that we had to go for a long period of time without any tool in place.
• Be more open to diverting from Design System guidance—upon reflection and discussing with others, the word "Calculate" feels more correct here. Plus, this icon approach clashed with another piece of guidance: "avoid using unlabelled icons".

A small business owner, Billy, came to us to see if we could turn his profitable 1-man band into a viable tech product business. "Loans 'r' Us" helps other small businesses secure funding for various needs.

Before jumping into a tech build, I convinced Billy to commit to a short piece of validation work. Less than 1 week to answer the question:

Can we turn Loans 'r' Us into a viable tech product business?

Overview

First an overview of the roles I assumed, the skills I used, and the team I assembled for the job.

Roles

• UX Consultant

Timeline

• 1 week

Skills and techniques

• Project planning and management
• UX research
• Remote user interviews
• User personas
• Customer journey mapping
• Workshopping
• Final report

Planning and research goals

After an initial conversation with Billy, I wanted to understand the problem domain better, then capture and communicate my findings back to Billy. Finally, the goal was to identify possible opportunities that could produce a viable Minimum Viable Product (MVP).

I did this by planning a series of activities:

1. Conduct user interviews
2. Capture user archetypes and Jobs, Pains, and Gains
3. Capture customer journey maps
4. Host an opportunity workshop

Each stage was designed to consolidate information I had discovered, replay it to Billy for confirmation or adjustment, before carrying on to the next. The final workshop is based my experience with the Design Sprint, to use everyone's collective knowledge to find areas of highest value to investigate further.

Even though I already have a main goal of identifying if we could create a tech product business, I always recommend using hypotheses to guide the research.

My hypothesis was:

H1: Billy's clients want to use a productised version of Loans 'r' Us.

and the null hypothesis:

H0: Billy's clients do not see value in a productised version of Loans 'r' Us.

Understanding the problem domain

User interviews

Why: user interviews are a quick, cost-effective method of understanding the business, Billy's client's perspective, and I can ask open ended questions.

I interviewed 2 of Billy's customers who were available, as well as Billy himself.

My questions were:

• How did you come across Loans 'r' Us?
• What did you originally contact Billy for?
• Can you tell me about the process end-to-end with Billy?
• What was the best thing about working with Billy?
• How about the most challenging thing?
• Can you describe Loans 'r' Us in 3 words please?

User archetypes

Why: I wanted a concise, memorable method of discussing who Billy's customers are and what their motivations are.

Using the information I had gathered, I was able to distill 3 user archetypes that represented the 3 types of customers Billy had. Each have their own needs from Billy, and financial needs.

Customer journey maps

Why: as well as understanding the customers profiles, I want a clear concise way to understand their experience with Loans 'r' Us.

I created 3 maps: 2 were based off the interviews I ran, and 1 was from Billy's perspective.

Here's one example:

Identifying opportunities

Why: use the best-hits from the Design Sprint process, to identify opportunities that Loans 'r' Us could pursue with us.

I printed off all the deliverables, created a basic map, and invited everyone to a dot-voting exercise. This helped me identify clear themes or starting points we could work from.

Outcomes

Ultimately I concluded that there was not a viable tech product business for "Loans 'r' Us", and we did not proceed to a build. This was due to all of Billy's customers preferring the person-led approach from Billy himself.

Therefore, I accepted the null hypothesis.

I did however identify 3 key themes or starting points, where technology and off-the-shelf software could help scale up Billy's business instead:

1. A “Compare The Market” for Business Loans—while possible, it's not for Billy's existing customers and wasn't their main pain point
2. Workflow Management & Automation—to scale up Billy's workflow
3. Financial Education for SME’s and Sole traders—to answer Billy's clients' questions in a scalable way

In addition, I wrote and shared a full report of work undertaken.

How I architected the design, development, adoption, and governance of the Design System at Residently consisting of over 100 components. Complete with Storybook, a zeroheight-like documentation, Figma libraries, and Atomic Design file structure enabling us to reach an incredibly ambitious deadline and improve quality to boot.

Hint: it requires collaboration.

Overview

Timeline

• 1 year and 6 months

Roles

• Technical Lead - 1 year
• Lead UX Designer - 6 months

Team

Over the entire effort, I collaborated with every single person in the wider product team. This consisted of:

• 3 UX designers
• 5 Technical Leads or Architects
• 3 Product Managers
• 20+ Software Engineers
• Head of UX
• CTO
• VP of Product

Part I: "as a Technical Lead"

Assessing the situation

As keen as I was to get started on one of my passions, I understand how important it is to observe and learn before taking any action. This not only respects the existing team and how things currently work, but also allows me to be made aware of any limitations that may exist. Doing so helps me prepare a strategy to best approach instantiating a solid Design System.

Some of my findings included:

• There are some basic attempts at design tokens in the code
• Design and Engineering were unaware of each other's efforts
• We had 9 different back buttons coded in the mobile app

Testing the waters

Once I realised that I could add some value by looking at the Design System, I started raising tasks on the Trello board to help with the effort. I used the "Discuss" facility—this was a way we could track all the tasks that we thought were important to be aware, but weren't a top priority for any of the product team. We had a rota where all engineers would eventually work on one of these tasks, so I felt it was a great place to start teaching others and bringing awareness to a different way of doing things.

Garnering adoption amongst Engineers

I held a talk about Organic Design Systems to an external meetup, but a couple of colleagues joined me. From there they could see a portion of the grand plan, and I felt that I had earned their respect when speaking with them after. This also enabled me to help gain allies and advocates of the whole Design System effort.

Organic Design Systems

Organic Design Systems Chuck Rice. 4 March 2021.

Google Docs

Spotting an opportunity to start

I wanted to move more towards Atomic Design and having organised, polished, reusable components that everyone knew how to use and compose.

"I knew Atomic Design was for the Engineers to have a common language... I didn't realise it applies to Designers, too!
— Sam Phillips, CTO at Residently

• Introduced the idea during standups to my product team
• Held a walkthrough session to "pitch" how it'd work to my engineers in the codebase
• Had a greenfield project, neighbourhood, we could lay the foundations and provide surface area

Collaborating with Design

Once the engineers had a rhythm and we fine tuned our approach to one everyone agreed on, I turned my attention to collaborating with design. Designers were the ones creating the handoff materials the engineers would use as a reference, so I was keen to start joining up both sides. One key event was defining the typography scale.

Originally, one of our designers had created a typography scale with 14 different variants. Double checking the mui library (material-ui at the time) we were only able to configure 13 variants. After jumping on a call to collaborate together, we settled on 13 variants that design as a whole could work from moving forward. Many other parts of the design system in Figma was defined in this manner.

Part II: "as a Lead UX Designer"

After negotiating a change in role at a time when I believed my team was more than capable and had the tools and processes to make good decisions, I migrated into the Lead UX Designer role. This gave me an opportunity to fill a skill gap in the team, as well as take the Design System even further.

Here's a summary of the key deliverables and milestones:

• Deliver a Design System Theory session to the wider team
• Conduct 2 Figma tutoring sessions
• Figma files: components, typography, colours, grids, spacing,
  (Later consolidated this to: styles, components)
• Knowledge base in Library (getoutline)
• Setup a Design System Kanban board to manage and prioritise incoming work
• Sharing updates: weekly summary, fortnightly show and tell
• Contributing: take onboard show and tell feedback, messages in channel, and fortnightly refinement of the backlog with designers at first

Deliver a Design System Theory session to the wider team

What: I hosted a 30 minute session to the wider team about the theory of Design Systems. The presentation deck is available below:

Copy of Design System: Theory

Design System: Theory Chuck Rice. January 2022.

Google Docs

Why: I wanted to set some clear expectations of what I aim to deliver:

• what are tokens, components, and patterns for designers and for engineers
• the broad lifecycle—how patterns are found, captured, and accessed
• the product defines the patterns, not the other way around

Conduct 2 Figma tutoring sessions

What
I delivered 2 interactive sessions using a set of prepared exercises, that I used to help teach more about assembling prototypes and Auto layout.

• Figma Training I
• Figma Training II

Why
If as designers we're using differing techniques to assemble our prototypes, we're not going to get the best out of the components of the system. In a previous role I quickly learned this makes a difference. In addition, I could learn if there were any new techniques that the others were using that I wasn't yet aware of.

My goals were to:

1. have a consistent method of assembling prototypes
2. raise awareness how to balance pixel precision with speed
3. build proficiency with Auto layout

Setup Figma library files and structure

What
I did a stint of consolidation activities to complete, simplify, and organise a collection of styles, components, and patterns using Figma's "Team Library" feature.

Why
To provide all designers a clean, robust starting point to build the prototypes needed to design and illustrate product features. With a consistent set of building blocks, I aimed to:

• Ensure Figma files were easy to update or fix retrospectively, as required
• Avoid trivial or repeat questions from Product Managers and Engineers at handoff time that aren't about delivering business value
• Reduce the amount of copy/pasting of rogue components that could be composed better

Learnings
Originally this consisted of individual files for: Typography, Colour, Grids, Spacing, and Components. After watching an office hours level up by Figma and their Config conference in 2022, I consolidated this to simply Styles and Components.

We didn't have a broad enough brand or set of styles to necessitate independent files.

Setup 30 Figma components with Properties and Variants

What
We had an existing set of components, but they weren't using the latest features available at the time. Properties and Variants were used lightly, but could have been utilised more to balance interpretability and buildability for engineers, but ease of using and composing designs for designers.

Why
Many different states are set up manually by designers, such as error states or adding in icon adornments, and weren't consistently matching how the mui library provided them.

To reduce effort spent on updating states and adding icons by hand, using the Material Icon pack and providing 80% of components and their states we most often gave us a massive boost to efficiency within the team.

This way, we could focus on solving the business problems for our customers instead of solving and agreeing how to implement standardised and recognised building blocks of the web.

Build a knowledge base

What
Similar to tools like zeroheight, I used our internal wiki tool "Outline" to start curating a Design System library. This covered things like "Getting started" for each person's respective role, to the roadmap, changelog, all the way to detailed patterns guidance such as "Forms" and "System feedback".

Why
In my theory presentation I mentioned that the anatomy of a Design System is spread out, and you'll see and use different parts depending on your role in the business. By creating a "starting point" I'm able to always refer everyone to one place and provide the extra guidance required to explain nuances of Components and Patterns.

From there, I could build a habit amongst each of the product teams by signposting to Outline whenever a question arose. Often this was either when the guidance could clear up confusion, or I could capture brand new guidance that didn't exist yet.

Setup a Design System Kanban board to manage and prioritise incoming work

What
I created a backlog and Kanban board of work in our project management tool ClickUp for the Design System work. I used Kanban since that's how the wider team was already working, and my time could sometimes be spent assisting more complex design efforts or substituting into a team at a moment's notice.

Why
I wanted to:

• clearly indicate to anyone at any time what I was working on
• show to others what work was on the near term, and the long term
• provide a facility to gather input from others, and facilitate any collaborative prioritisation sessions
• when the time arose, enable others to get involved by delegating subtasks

Sharing updates and changes

What
I did a weekly summary message in our internal communication tool, Slack, covering what I did the previous week, and what I intended to do during the current week. In addition, I hosted an optional fortnightly show and tell session that everyone was invited to.

Why
By sharing a weekly written update I was aiming to keep the system forefront of people's minds, have a place to find the links to the updated or new resources, and have a chance to input to what's coming up. The show and tell session enabled me to share these updates visually, and facilitate any discussion and thoughts people had.

Enable contributing to the system

What
Take onboard feedback from the fortnightly show and tell sessions, encouraged messages in the #design-system channel, and setup fortnightly refinement of the backlog.

Why
Whilst I have my own preferences and opinions, the system has to work for the team. Taking on a servant-leader role I wanted to ensure that everyone felt they were able to participate and shape the system as it developed. By doing so, I hoped to share that sense of ownership around. I did get help and input from various individuals to grow it by either raising gaps, or fixing documentation and bugs.

Get feedback from the wider team

What
I did what I called a "temperature check" to get feedback on people's impressions of the system, if we were using the materials I was working on, and if anyone had suggestions for the roadmap ahead.

Why
I was keen to improve how everyone felt about our design speed and design precision. In addition, my perspective is different and I wanted to see what I could be doing to help the team further.

Learnings
One fantastic outcome was that storybook was difficult to find as it used the Heroku generated URL. I immediately created an easily memorable URL and shared that out to the team.

Part III: upgrading from mui v4 to v5

Overview

Doing this upgrade involved:

1. 2.5 months of work (since April 11)
2. Nearly 300 files updatedAlmost 200 components updated
3. Almost 200 components updated

Additionally, I had a small amount of help from our Technical Architect at the end to finish migrating the DatePicker component. This was in order to deliver the upgrade within a release window that would be minimally disruptive. Otherwise, I did 100% of the work.

There were four main reasons:

1. No more Materil Design updates: material-ui v4 was no longer receiving updates, only security patches. Any changes to their design patterns would not be reflected
2. Performance of the frontend: mui v5 provided better performing base components, particularly Box. I was keen to maintain a high experience standard for our partners
3. Ensuring a easily maintainable codebase: we have another codebase delivering part of the resident experience, that is difficult to work with and we assessed wasn't worth upgrading at all. It's quicker to rebuild in something new.  I wanted to avoid the same scenario
4. Saving engineer time: documentation on Google search results returned the v5 documentation, but until we upgraded engineers needed to navigate by hand to the v4 documentation

During the upgrade

Once I started working, I had to migrate all the components and remove the old material-ui dependencies before I could verify what was causing the failures. I discovered a few tests that were fragile, and a few that did not test what they said they did. It turned out to be a great auditing exercise to further improve code quality.

Briefing the Engineers

In order to prepare all the engineers for the incoming upgrade, I made sure to communicate using more than one method of what to expect. First I did a written update and a wiki article in the #engineerig channel. A few weeks later, I shared how they should style things moving forward in v5, and what types of migration style they'd see in a presentation. This facilitated a smooth adoption of the new work.

Copy of Copy of Mui v5 brief v2

µ-e v5 brief Chuck Rice. 7 June 2022.

Google Docs

Merging the changes

In order to have a smooth upgrade, I ensured that I had consistently passing runs on both the local test suite, and the integration tests across the platform. The integration tests are notorious for catching engineers out and usually had a 50% pass rate. After merging, my branch passed every stage the first time.

Outcomes

The core outcomes experienced were:

• Time estimate to rebrand the mobile app went from 2 months to 2 weeks—a 75% reduction in time due to design tokens.
• Designing features and fixes that used to take 1-2 days, could be delivered in as little as 30 minutes—99% reduction in time.
• Together with the weekly design workload planning I put in place, we went from 8 months delivery time to 4 months—in fact, 1 week ahead of schedule.
• It only took a few days for another Engineer to deploy a resident-facing microservice from scratch, borrowing the setup and components in neighbourhood.
• 0 test failures and 0 functional production issues were raised after I migrated the entire neighbourhood codebase to mui v5—300 file changes made over 10 weeks

In addition, these are known outcomes that any Residently employee (past or present) can also atest to:

• Consistency in our methods and basic design patterns enabled designers to swap tasks at a moment's notice, due to illness or holiday for example.
• Countless discussions were resolvable by referring to agreed documentation.
• Engineers were able to compose and release features more quickly with less effort, and less chance of bugs.

Bonus: it helped further my colleagues careers

What I hadn't planned for, but was pleased to hear, was that the principles of Atomic Design and the Design System were helping those taking that next step in their careers.

"I did a tech test and organised my components into atoms, molecules organisms. They asked me what's that, and after I explained it was grouped by complexity, they responded "oh, that's a good idea". I think that got me the job."

— Ed Payton, Full-stack Engineer (Ruby on Rails, React, NextJS)

Further work

If I had more time, I would love to:

• Make components sharable between all our frontend apps—when I exited the business we had an npm dependency that could share some basic components, but I was keen to use something like bit.dev to make it more sophisticated.
• Flesh out "template" and "formulas"—I firmly believe that the product defines the patterns and not the other way around. As the product expands, more and more patterns start to emerge. Eventually I can create formulas that anyone can use like Lego or IKEA instructions.
• A stand alone "https://residently.design/" knowledge base—whilst our internal knowledge base is great as is, being stand alone both elevates it and I can better guide people coming across it for the first time.

The UX team at The Co-operative Bank had a budget of six weeks to influence the migration of the smile.co.uk website, before development began. I volunteered to step up and take on the challenge.

Here's how I did it in just four weeks.

Overview

First an overview of the roles I assumed, the skills I used, and the team I assembled for the job.

Roles

• UX Lead
• Agile Scrum Master

Skills

• Project planning and management
• UI Design, Content Design
• Stakeholder Management
• High fidelity prototyping
• Design Systems

Team

• Product Owner
• Senior UX Researcher
• UX Researcher
• UX Designer
• Content Designer

Problem statement

There were two main drivers for the overall project:

1. the existing Content Management System (CMS) required development effort to update
2. the existing hosting contract was due to end in 5 months time

In addition, I had two personal goals I wanted to achieve with the project as well:

• apply all the contributions we made to Daly—our Design System—from working on the main Co-operative Bank website
• meet AA WCAG accessibility standards, in-line with the bank's leadership goals

To ensure it went smoothly, I worked with the Product Owner to identify all the key stakeholders, nominate one person to be the "decider" for key decisions, and align everyone to the same direction.

As part of aligning everyone, I did a proposal kickoff session, and shared a Design brief based on all the context

Design brief:
"Migrate Smile content to dotCMS as quickly as possible so we can give back control to Service and Journey over workflows, and leverage the goodness of Daly design patterns."

Preparing the project

There were three main tasks I set myself, to best prepare for the project and set it up for success.

Analysis and information gathering

Talk with our Product Owner, leverage their preliminary analysis, and do some more gathering such as gathering the Adobe Analytics data, any previous work, and assessing what’s possible.

Assemble the team and get input

I held two separate sessions, one with the internal UX team to see if the plan looked reasonable, and fit into our existing workloads. The second session was to replay the plan to the wider stakeholder team to set everyone’s expectations.

Create a design brief and a project plan

A rough finger in the air estimate that can be shared out and refined. Tangibility is important for collaboration, so the focus was put on doing the minimal amount possible to get the maximum return. Using existing design patterns we had previously used, refining the headings, links and call-to-actions, as well an iterative research strategy gave us a solid approach.

Design

Implement Agile methodologies

With such a tight deadline I opted for a 1-week cadence of planning, designing, then delivering. This was to keep communication high and keep stakeholders involved regularly. Putting in the usual ceremonies of daily standup and weekly planning sessions, as well as a Kanban board in Jira facilitated it.

Set up a micro Design System

We had Daly setup with the Co-operative Bank theme, but didn't set it up for Smile. The first week was mostly dedicated to developing a Smile component palette. We design in Figma but only used the free version, which means only styles such as colours and fonts can be shared between files. A single palette with all the components we needed, identified after a round of analysis, would speed up our workflow significantly.

Set a research strategy with a "big bang"

In order to bring all three disciplines of Design, Content and Research, visual digital whiteboards allowed us to making the thinking tangible and allow everyone to interact. It helped to make sense of the new pages we had to create, and rework the information architecture of the global navigation. It gave Content designers the ability to interface their IA skills, and Researchers to feed in their previous insights and refine our research plan.

Assemble the Mega Prototype

Once the research strategy was in place and the components assembled, it was time to produce prototypes in order to hit the research goals. Alongisde supporting workshops, I divided up and delegated parts of the website to individuals or pairs to work on. I spent my time creating and delivering screens in a collaborative fashion, as well as reviewing the work others had done and highlighting or fixing adjustments needed.

Delivery

Comprehensive handoff documentation

I started a set of pages within Confluence to deliver HD mockups, component structures, link tables and content docs for each page. Why? Bank laptops don’t all have access to Figma, not all stakeholders are from a tech background. Confluence is a neutral ground, and is an audit log of who delivered what and when. Also, our limitation of free Figma means files often are tied to individuals and are at risk of becoming lost.

Regular stakeholder demo sessions

Demo sessions give us a way to showcase our progress, open up the floor to questions and critique to adjust our direction of travel, and serve as a paper trail audit of our work. In the past the bank has had design work questioned, and with a paper trail no more extensive than a Figma file we sometimes struggled to justify decisions or supply adequate rationale. Together with a backlog we now have a solid paper trail of evidence.

Outcomes

1. Delivered 33% faster than anticipated
2. 17.5% of all pages redesigned
3. Nominated for 'Digital Spotlight' showcase to senior management

After handoff to the development team, a grand total of 3 build issues were identified when scoping the build tickets and sprints.

All were trivial fixes.

Challenges

Transitioning from the previous project

Since the team and the wider bank were not all yet versed in Lean UX and Agile methodologies, the project started 2 weeks later than planned. This is fine in Agile methods, and we simply prioritise our work. As part of the first week splitting up the site, we could get a good sense of what was achievable and the weekly demo and planning sessions, as well as stand ups, enabled us to keep a pulse on our progress.

Working with a young Design System

Our design system, Daly, is still truly in its infancy and has been restructured twice in my time here already. It needs a lot more work to be organised, comprehensive, and documented for non-design teams. Combined with only having access to the free version of Figma proved challenging. Budgeting more time to prepare a Component palette to work from, as well as documenting the delivered work in Confluence, helped to combat these limitations.

I designed and implemented an update to the visual language and hierarchy of Spoked's existing website, based on a pre-prepared SEO content and goals. In addition, I wanted to ensure it met AA accessibility standards, and is completely mobile responsive.

This is a paid project, and is now delievered and live; it can be viewed at https://spoked.ai/.

Overview

• Client: Rich Lang, Founder of spoked.ai (LinkedIn, Wikipedia)
• Role: UX/UI Consultant, Webflow Developer
• Timeline: 2 weeks consultation, 4 weeks delivery

Webflow features used

• Symbols and Components
• Classes, combo classes, global combo classes
• CMS and CMS Template pages
• CMS import and export

Approach

Understanding the goals

Through various conversations, I learned that the visual language of Spoked's mobile application had evolved and become more refined. This left the website feeling dated and out of sync, and forms the first goal.

I performed a UX audit as a pre-cursor to this project, which gave me a deeper understanding of the visual language and where it could be improved.

In addition, Rich has been successful in meeting many organic SEO goals such as page ranking, the "people also ask", and knowledge panel snippets. Results were mostly content driven using blogs, so he wanted to double down on the site-wide content as a whole.

In summary, the goals are to:

• bring the website's visual language in parity to the mobile app
• express his content and SEO strategy visually, site-wide

Review and audit the existing UI

Part of understanding what needs changing, is understanding what's not working. I spent some time assessing what's executed well, and what could be improved and took into account the core SEO goals of trying Spoked, and the B2B proposition.

The landing page hero for example is laid out well, but the buttons could be visually misinterpreted or easily missed over. In addition the navigation didn't share the features—a common page viewed by customers before making a decision.

Another example is the "What is Spoked?" page. Here, the primary copy section is center aligned, which makes it difficult to read. In addition, while the use of spacing is great to separate the sections, there's no set foreground and background.

To improve this, using UI elements such as Card UI, and using a darker shade for the background can make the three features below stand out more. We could also use Card UI for only some elements, to set even more of a hierarchy and draw attention to the critical parts.

Orientating myself

This was my first webflow project, and I wanted to get acquainted before tackling the more complex parts of the project. I decided to spend a working day, roughly 8 hours, experimenting and trying to replicate the home page.

Afterwards I learned I needed to strategise and firm up the visuals first, whether hand-drawn wireframes or Figma mockups, then execute. Allowed me to more rapidly explore ideas visually, and freed up my time to learn how to execute within Webflow.

Rebuilding a design palette

From my in-depth experience building an end-to-end design system, I knew I needed at least a basic style palette to work with. I assessed what we had, and assembled the following:

• A basic typographic scale I can semantically marry up with web best practices
• A colour palette I can use to add depth and elevation as necessary
• A spacing scale that's quick to use, and sets a modern visual flow

Adjusting the visual hierarchy

The existing design language was flat, whereas the app had gone more torwards a card-based language. In addition, the goals both Rich and users had could be better catered for in terms of UX.

There's a few techniques I used to improve these:

• The 60/30/10 rule of colour theory—a few subtle tweaks visually brings everything together as a whole.
• Card based UI—it not only aligned to the app, but is also a UI pattern that helps to chunk information, and give the eye more direction of where to travel.
• Introduce elevation from Material Design—not only is it modern, but this helps keep key information for SEO in the background, and bring forward key info we want users to consume and act upon.
• Adjusted the CTAs elements—based on the goal of a page, I swapped the CTA element used. e.g. Buttons have higher prominence than a Link.

Improving global navigability

Using my past design experience on both Co-operative Bank's website and Smile's banking website, I updated the global navigation to better suit some common tasks users wanted to do. Some goals I aimed to achieve were:

• enable users to navigate backwards or up the site hierarchy
• give full visibility to all sections in the footer
• make the help centre and download app links easier to find

Given the new content strategy was flat, never being more than 2 or 3 levels deep, this made it straightforward.

Delivering the results

A mobile-responsive website

I didn't approach this project mobile-first, but I was keen to keep it mobile responsive. All components were designed to display well on tablet and on mobile.

Documentation

While often overlooked, my goal is always to keep the client in control. Providing just enough documentation means someone can make some changes, without fear of upsetting another part of the site.

What I learned

Webflow classes are shared between components

This adds a layer of complexity you simply don't have in Figma. Edits can accidentally change properties related to a combo class, that's used elsewhere. It's very easy to make a mistake if your concentration slips.

Variants can be achieved by setting display to none

Whilst only some properties can be changed and configured in webflow, you can toggle the visibility of almost anything. Your components will be heavy, but you can add more flexibility by doing this.

It was also the principal I used to make images display responsively—I set up 6 classes respectively:

• desktop-only
• tablet-only
• mobile-only

CMS in Webflow is powerful

Once I gave myself some time to understand the CMS capability, it was really straightforward. Once I set up a collection and the fields I want, I get a template page for free for each CMS item, and I can make my own custom page with a Collection List to display them all.

ClosedBox is a training and development consultancy, teaching "soft" skills to employees such as leadership, delegation, or critical thinking. A pair of work colleagues, one managed by the other, sought to productise part of their offering as a tech product.

After positive initial conversations, development had begun in earnst, but I quickly found the project struggling with a consistent direction and fact based decision making. What's more, the project was geared up to spend it's entire £300k budget before involving a single end user.

For me, that prompted the question:

HMW gain confidence in and influence our product direction and decision making, before spending the entire budget?

Overview

First an overview of the roles I assumed, the skills I used, and the team I assembled for the job.

Roles

• UX Consultant

Timeline

• 2 weeks

Skills and techniques

• Design Sprint

Approach

I arranged and performed a Design Sprint to:

• Engage key stakeholders
• Gain everyone’s understanding
• Make our thinking tangible
• Perform timeboxed interviews with users

Running Design Sprint 2.0

I used the Sprint 2.0 methodology from AJ&Smart. There were a few reasons I opted for a Design Sprint:

1. Our target users had up to 14 hour work days; we needed to be efficient.
2. We needed clarity as quickly as possible, to determine if we were digging a rabbit hole.
3. Gathering buy-in was easier using a tried and tested methodology.

In addition, I made some some modifications for my use case.

Modification #1: Workshop format

Since the ClosedBox were based over 1 hour away, and the co-founders could only spend one day per week with us, I broke things down into a series of bite-sized workshops.

Modification #2: System modelling

Everyone seemed to have different understandings. I asked everyone to draw how they understood the problem domain and share it amongst ourselves, before consolidating it into a single view. See ‘drawtoast.com’ for more.

Modification #3: Internal ideation

I made a judgement call to rely on the clients’ strengths and include them during idea selection, whilst educating my team further during ideation.

Modification #4: Note-taking delegation

In hindsight this was the most powerful. I convinced one of the co-founders to take notes during test day, resulting in them gaining a deeper appreciation for our target users.

Seeing is believing.

Challenges

I was only able to involve one of the co-founders directly in the user testing phase. Ultimately, they saw the need to pivot while the other co-founder did not.

A debrief is no substitute for experiencing the learning first hand.

Outcomes

After debriefing the client and our internal team we made a pivot of the project, and launched a pilot test at 50% of the budget spend. Previously this had been 90% or higher.

In addition, I found out one of the co-founders left some time afterwards, and a year later started their own version based off the learnings from our Design Sprint together.

At the end of the day, it's about calculated risks, and I wish them both success.

One of the most important things for a startup or small business is to have every single member of the team aligned to the same process or way of working. With the same goal, same language and same framework used to approach new clients you get a unified team that excels at what they do. I'm going to show you how I discovered that our team's understanding was fractured at thestartupfactory.tech, and how I worked to articulate and unify it to eradicate "what happens next?" conversations, give prospective clients the same onboarding experience no matter the type of work they need, and improve our sense of identity as a company.

Throughout this project I followed the "discover, design, validate" approach of conducting design work.

Discovering the problem

As with most design challenges when you realise something isn't right, you need to perform some discovery activities. This helps probe around and determine the current state of affairs. After noticing that I spent more time asking around what happens next instead of making progress for our clients, I conducted what's known to some people as a 'Listening Tour' or 'Empathy Interview'.

I went around the team one-by-one to ask a simple question:

Can you draw out our process on a piece of paper?

Even though I did the actual drawing, the results were enlightening—we each had a different view of how things were done. Collectively we covered the bases end to end, but it was possible for key activities to fall through the cracks undetected. It hadn't happened yet, but I wasn't going to sit around until it did.

Onboarding

As with any complex process, if you get the beginning right then great results propagate downstream. After speaking around the team and making a few sketches I assembled a diagram to share what I had learned what our individual perceptions were of the onboarding process. With this I conducted an ideation workshop to see if others saw the same problems I did, if there were any I missed, and how we might be able to solve for them.

My conclusion from sharing this diagram and performing an ideation workshop was that I jumped too quickly into it, and was too detailed. I used good methods at the wrong time. The team understood it but I didn't take the time to align our expectations first of what we're trying to do, before moving on into discussing the variety of problem areas or difficulties we often encountered.

D'oh!

I could have abstracted it and retried the ideation workshop but I figured there wouldn't be enough to work with. I decided to take a step back and try to capture the whole process in a single sheet of paper.

The entire process

Learning from my mistakes, I took extra time to draw up the various methods we believed we put into practice so far. Only after checking these with the team to clear up any confusion would I move on to critique, improve and consolidate it.

Here's just a few drawings I captured:

A few different models came out and I managed to capture them as three distinct methods, complete with catchy names:

What I wanted to highlight in the above diagrams to myself, as well as the team, is that the purple boxes are the stages I've introduced to our process over the years of concentrated design efforts to get market feedback. It could be coffee shop testing, internal critiques, or controlled pilots with prospective customers when we do a launch of the product. If what we were creating was wrong, we needed to know as soon as possible. Representing it this way made it crystal clear they needed to be formalised further and embedded into the DNA of what we do.

Designing the process

Now that the discovery and definition work had been done, it was time to move into the 'design' phase. After noting these down I did these activities:

• design sprint style map
• 1-2-1 critique sessions

The map exercise within the Design Sprint is a common tool used to tackle complex business problems and produce money-making solutions. By mapping out how things work into a single view and agreeing on it as a team, you can then discover and make impactful changes. I thought "surely, it was fit for purpose?". Below is the first version:

After producing a first version and digitising it, I ran a few 1-2-1 sessions with members of the team to gauge feedback and collect notes. I wanted to see individually what people thought was right, what was downright wrong, and what suggestions everyone had from their own perspectives.

After amending based on feedback, I kept iterating, and ended up making 3 full versions before taking it to the next stage.

From here, many mapping activities and even user journey mapping suggest separating things into phases. I was comfortable with this as part of my Task Modelling exercises and decided to have a 'Pre-build', 'Build Iterations' and 'Post Build' phase. These made it more clear what needed to happen between each stage, and that whilst we're creating a tech startup it will go through several revisions and releases before we're done with the initial investment.

From here we made great progress, but I needed everyone to come together. With the buy-in done from key members I wanted everyone, including the key directors involved in day-to-day running of the business, to input into the final solution. It took several months of planning and and office move, but we managed to come together in a 'Round Table'.

Validation: the Round Table

What is the round table? It had two parts: first was to share the diagrammed process above, and second was curating a list of activities done in each stage. After sharing the process in the first half of the meeting, it turns out that the structure of the diagram was already in a good spot. Winning! We were bound to need to change it eventually over time, but having this as a starting point was the most important milestone.

One activity that bit us in the past was not making it clear with founders that they needed to establish a marketing plan and strategy, particularly for B2C propositions i.e. anything that you or I might use. We had agreed that it was critical to highlight this, so that's why we came to the conclusion to pad out the rest of the activities split into 'TSF' activities and 'Founder' activities. I ran a Lightning Decision Jam style workshop to set the scene, generate possible activities, vote on what we thought was most important and add them to the final process diagram.

Dot voting is a sure-fire way to spot a fan of the Design Sprint method and sometimes Design Thinking as a process. Here, I handed out the appropriate number of dot stickers for each person to vote on what they thought had to be on the final diagram, interns and directors included. Vote for your own things, all the dots on a single post-it or spread them. Doesn't matter as long as you use them. No circular discussions, just working efficiently to create the first official version of our process and way of working.

One of our members couldn't make it to the voting session, so I created an online Google forms to try and capture their vote. It didn't really work and I got their votes separately, so I'd suggest trying a different tool next time.

Where we are today

After all of that work, iteration and consolidation, I think we arrived at quite a healthy result. With the hard work of establishing a sound structure underneath and having content that's as correct as we can make it, I re-created the diagram in a printable format using the mini-design system I created in Figma. In keeping with the mantra of "release early and often", here's version 4.0.1 of the process at thestartupfactory.tech:

This is still a point in time and there's plenty of work to be done to not just fine-tune how we do things but create and enrich the supporting templates and infrastructure. For example, there's now a framework for carrying out 'due diligence' work before reaching our bread and butter work. So far the feedback internally and externally seems positive—people are talking about it and are using this to facilitate conversations. There are talks about printing it for the office.  I suspect that this forms the basis of the core TSF.tech process for years to come.

Conclusion and Next Steps

Overall, I'm pleased where we got to. It's been a lot of work just to round up people let alone do the actual work of constructing the tangible diagrams in-between client work. Whilst we have the internal buy-in and approval of the process, there are several steps that can be carried out to take the validation to the next level and really prove how robust this new model is. Even if I'm happy, our clients need to be happy and the results need to speak for themselves.

What we gained:

• Every person in the company aligned to a single way of how we do things
• Countless hours saved by eliminating "so what do we do next?" conversations
• Ability to address any weaknesses in our method, now that it's a single page
• Startups should hit revenue more quickly, if following the checklist activities
• A graphic to facilitate conversations with prospective clients of how we work

For myself, I've proven and learned the following:

• There's a great deal of work, yet reward, for true collaboration
• Content and structure is king—get that right first and the rest will follow
• Use a design system, no matter how small. Countless hours were saved here
• Dot voting is still oodles of fun

Next steps:

• Set and track KPI's such as "time to start project" and "project stall frequency"
• Identify and collect key quantitative analytics of project performance
• Identify and collect key qualitative feedback internally and externally
• Set a check-in point to iterate on this process—does it match reality?

Even if it works better performance wise, if we find that everyone loathes one part of or the entirety of this methodology, then that's a signal to listen to. As a designer my job is to ensure that we're not only exceeding expectations, but that we get satisfaction out of it too.

Originally published: 2020-02-24.