Talking shop & my UX process

Overview

Every project comes with its own set of challenges and can vary a great deal in which approach is most suitable, more often than not, time and resources are tighter than anyone would like but the commercial reality always dictates and I always strive to achieve the best possible result.

Below is a basic overview of how I like to work.

Learn

What problem are we solving? Why is it an issue? Through a number of meetings with stakeholder holders and team members I start to build my own brief, collecting qualitative and quantitative data, interviewing relevant people, collecting facts and opinions and discovering what success looks like to the business.

At this stage, the goal is to fully understand the problem and why we are fixing it; often the real problem is different to what was first highlighted or assumed. To really understand this I look at the user and I try to understand their point of view: what do they need? Their true needs often don't correlate exactly with what they think they want.

Once I have a clear understanding I am able to draft a new UX brief with some clear KPI's.

Research

New projects require a wider market view by evaluating competitors and general market research and checking technical dependencies and limitations. Once the initial user research is done I can follow with persona creation, task analysis and interviews.

Concepts & Ideas

Now that I have a full view of the problem I usually like an ideation workshop with my team, I like to include non design team members if possible, PM's, Devs it's great to get everyone involved; creating quick sketches and noting down ideas with no judgment; just a free flow. I like to have a clear list of concepts which I can weigh up against user's needs and company goals to find out which ideas align and meet our KPI's or are most likely to.

Following this, I'll have a meeting with the PMs and often the engineers to run over the reality of building said concepts - some ideas may be much more expensive on engineering time to produce than others and others might not be suitable due to system dependencies, api limitations etc. At this point, we can lay out those that are worth pursuing given the circumstances.

Build

I can then start designing multiple solutions to the user problem, creating very basic wireframes (usually using Axure to create quick "no-frills" UIs to test or InVision for High fidelity prototypes). This allows us to very quickly ensure all content is accounted for and that dependencies and edge cases are picked up - I want to test the concept makes sense and works before we invest time in applying the UI to it, or if it's a new product, before designing the UI at all, however, sometimes certain prototypes are best user tested in high fidelity as UI does affect results, depending on the project at hand.

Test & Measure

The next thing to do is test it: this involves creating a test plan, forming a hypothesis to validate against and recruiting participants. There are many methods for testing, such as, moderated in-person or remote usability testing, card sorting, heuristic evaluation, click testing, A/B & MVT testing and so on, it really just depends on the project and what we are trying to measure.

I can evaluate the results of the tests conducted on these prototypes against the objectives and quickly find which concepts are worth optimising. This process consists of analysing, re-designing (optimising), testing and iterating until we have a sound, high performing solution that meets the KPI's and I can then push the solution to full UI design.

Of course, any process really depends on what the project is, but I hope this gives you an insight into my thought process and the way I like to work. There are a number of ways to tackle any problem and I'm always keen to learn and discover new processes to enhance my work and the results that myself and my team can produce.