Portfolio

Some projects I'm proud to have worked on

Talk It Out

Helpforce I&I

What is this?

This is a collection of recent projects (last 2-3 years) that I’ve worked on. On all of these I lead the design, working from start to finish. However, I am no solely responsible for them. Building products is a team sport. I’ve worked with some amazing, talented individuals who have shaped this product just as much as I have.

How it’s structured

There is a page for each project. Each project gives you some context on the team that worked on it. The core of the page is split into 3 sections that guide you through the lifespan of the project.

Background

I’m a writer. I can write about design and the process all day. However, I know as a hiring manager or team reviewing this, your time is precious. I also know that what you’re looking for is to get a basic understanding of how I design. If you like what I’ve done, the deep dive will be bette served over a 1:1 video call or interview.

With that in mind, I’ve summarised the key points on each project. I’ve written up the background of the project which hopefully gives you context on what problem we tried to solve, how we knew it was a problem, and what success looked like.

What we did

I’ve recorded a short video running you through the solution. I’ve also added links to key flows and artefacts I used on the actual project. Things like workshop boards, Figma files, notes etc. I think these are cool to share because not only can you tell a lot about someone from how their layers are ordered but it lets you look under the hood to see how it all works.

Outcome

Finally I’ve summarise the outcome. I’ve included what the outcome of the project was and how we achieved (or didn’t) our intended goal, why I think we did/didn’t, and what we plan to do next. I’ve also added two other sections: What went well and What didn’t. We do retros after every project or everything we ship to look back at how we felt we performed as a team. I’ve taken the highlights from these, as well as added my own personal reflections.

I think any project has trade-offs in it and some things go better than others. The more you can understand them, the more you can learn from them.

⁠

Design Process 🎨

As lead designer on these projects, It was my role to set the strategic approach design would take to solving the problem. My process, just like everyone else, varies on a lot of things. Mostly how long you’ve got and who you’re working with. Also I think process works best when it’s used as a series of tools to be called upon, not a linear set of steps like a recipe.

However, each project does go through 3 main stages: Understand, Define, and Execute

Understand

This is where I seek to understand what we’re hoping to do (duh). What problem are we solving? How do we know that’s a problem? Who is this for? Why do they care? Have we/somebody else tried to solve this before? Did they succeed/fail? Why? Asking these questions allows me, as a designer, to get to the core of:

Why? Why on god’s green earth are we spending our short life span doing this?

This is the ultimate goal. Once we know this we can see where this project fits in. We can start to figure out the key challenges and what we define as success.

This stage is typically where qualitative research and discovery happens. You run a lot of workshops, stick stuff to walls, talk to a lot of people – all that jazz.

Define

Once you are confident you understand the problem the best you can, it’s time to define actually what we’re doing. Often this is where teams want to start. They skip over the first stage. That’s natural. I do it all the time and have to pull myself back. This is the fun bit.

At this stage, we’re looking to fit the solution to the problem. How can we best solve the problem? What is feasible? What will most likely lead to success? Early-on, I think it’s important to start with quantity over quality. I do a lot of sketching, mapping, and prototyping. My goal here is to discover what I call ‘the foundations of the product’

For example, if you create a user journey – you want to look at your biggest challenges and see where on that journey they sit. The areas that have the biggest clusters of challenges are you foundations. If any of these bits falls down, the whole thing goes to shit. You can create the best dashboard you want, but if most of your challenges are around onboarding and you fail that – you’ve wasted your time.

These foundations are what I aim to rigorously prototype and test early on.

Execute

Then comes to the bit all designers love: the “actual design”. By this point I aim to have my foundations pretty much sorted. Validated and improved from users tests. I can now start to use my learnings to fill in gaps and work out how this whole things fits together.

During this phase, rapid rounds of feedback both internally (team reviews) and externally (usability tests) are vital. I believe it’s a balancing act to figure out where to spend your time and how long to spend on each part. It really depends on the product, timeline etc.

One of the misconceptions designers have (and I had early on) was that this means headphones on and smashing out 100s of screens. Instead, this phase is better served collaborating with engineers and PM’s to seek to push and shape the finer details of the product.

It’s the most collaborative part of the process IMO.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.