Good UX should be grounded in good process, driving creative thinking and problem solving throughout a project to ensure the end product has the best chance at success.

UX is a constantly changing and evolving profession and we are always learning how to improve our process, not to mention the insane speed that technology is progressing at. The one thing that is always a constant, good design solves problems.

Everyone’s process is different and I wanted to share a quick overview of how I go about designing things.

Design with intention

I am a big believer in Lean UX. The idea of validating your theories with the least amount of work possible. This doesn’t mean working less. It means working smarter. Not wasting time on theories that won’t work or are not worth the effort.

Stage 1.

Empathy

Research & Understanding

You cannot create a great experience if you don’t understand what you are designing and who you are designing it for.

“Get out of the building” –  Steve Blank

Learn about your audience. Learn about your stakeholders. Learn about the competition. Learn everything you possibly can about the current landscape surrounding the product.

Talk to people. Identify their needs, pain points, what they like, despise and what they think could improve the overall situation.

One thing to note here, take what people say with a grain of salt. The main point is to try and identify peoples problems and then create our own theories about how to fix them. Never simply build what ever people tell you to. Dig deeper.

A classic problem I see all to often is a company hiring a UX designer to just build what they think will fix the situation. Not to actually explore the real reasons for the issues in the first place. This sometimes works but most of the time it just misses the mark because the core issue was never discovered.

Going guerrilla

I am also a big fan of guerrilla testing. Going and talking to real people that might have an opinion on the project. Makings a coffee app? Go ask people in cafes about it. Buy them a coffee for their ideas. Making a travel app? Go to the airport and ask travelers a few questions.

Stage 2.

Exploration

Ideate

Ok now we have a pretty good idea of what the issues are, it’s time to start making hypotheses. Generating ideas about how we might fix the problem. Nothing is to crazy here. The wild ideas are the ones that usually lead to something awesome and original.

Create brainstorming sessions and design studios. Lots of postits and whiteboard sketches that have a life span of about 4 minutes until you scrap it for a better idea. Once the ideas start flowing, the solutions will start to show themselves.

Refine

Take your hypotheses and refine them. At this stage you will notice which ones are clearly not going to work and others that have great potential. Some will be in between, park those ideas and come back to them later if needed.

You only need to refine them to a stage where you can validate them.

It’s never to early to validate!

Validation of your hypotheses should be an on going process. If you are not always checking the GPS, how do you know you are going the right way. And don’t say you are good with directions because it’s an analogy and that doesn’t count.

By validating your hypotheses as you refine them, you can work on what matters. You can drop the less positive solutions and focus on the stronger options. You can re-adjust your theories as you progress to arrive at the best solution possible.

It might sound like a time consuming process but it’s much faster than designing, building and deploying a new shopping cart that no one knows how to use.

You can start validating your hypotheses when they are just a sketch on a piece of paper.

Stage 3.

Prototyping & testing

This stage is a bit of an ‘end if’ loop. We going around in circles a little. Ideate, refine, test, rinse and repeat.

This is also known as the Build, Measure, Learn feedback loop as discussed by Eric Ries, in his book The Lean Startup.

Here is where we really understand if our solutions are the right ones. We repeat this until we have a solid well rounded theories that is worth the effort of building.

Build the simplest possible prototypes to get the information you need. Is a paper prototype enough to show the basic layout? Or do you need a more complex Framer.js experience to show your complex animations. There are millions of tools to create prototypes at every level of fidelity. Just find what works for you.

By creating and testing an MVP at it’s earliest stage, you can find problems quickly, allowing you to either fix them, or pivot to a new solution and avoid wasting time.

Test test test!

Get your prototypes in front of people. I don’t care how you do. Just get them out there! One key thing to remember is you want honest feedback. Don’t ask leading questions or explain things that cannot be learnt elsewhere, for example, only give them the info that they can read in the app store when downloading the real thing. The user won’t have you around to help remember.

Again, as each project is different, the methods of testing change. You need to know what is best suited to your situation. Just remember to focus on what you need to learn from the tests and work towards discovering that.

Stage 4.

Learn

Learn from your tests and refine your theories. Re-align your product to fit with the needs of what this new data has shown. If your solution is on the right track, make it better. If it’s missed the mark and didn’t return good results, you need to decide if it’s worth continuing to refine or pivot and go with a new solution.

To pivot is not an easy decision. Dropping all the previous work to move on to something new, especially if you have already invested a good amount of effort into it can be de-motivational to say the least. By identifying problems and seeing the need to change course earlier will be less painful.

Moving forward

Production

Usually in an agile environment, the build is running in parallel with the design. Once the concept is at a point where we have a basic idea of what is being built, there is plenty of work for the dev teams to get started on most of the time.

Many designers believe that you can just whip up some designs, dump them on the developer and head down the pub for a beer. This is simply not the case. A UX designers job runs the entire length of the project. Working closely with the dev teams and business teams as requirements change and technical difficulties are tackled.

Far to often a designer will hand over their designs, a technical problem is found during the build phase or business needs change and with no more designer, a quick fix it jammed in without much thought. It can be pretty damaging to the overall experience. Not a great result.

In the end

UX is not just a bit at the start of the project to get the ideas drawn up. It’s constantly validating and ensuring the product is maintaining the right course to providing the best solution for all parties involved.

It’s understanding the user, the business and the tech teams needs throughout the project.

I will always be refining my process as I learn and experience more.

 


Thanks for reading. Don’t forget to check out my site!

www.agkdesigns.net

Advertisements