Basketball Hoop

Running the Baseline: The Basic User Experience Process

One question I see discussed on many UX forums is one that new professionals have a hard time understanding– what, exactly, is a baseline UX process?  Regardless of what you’re working on, what are the steps that every UX professional should, as a general rule, take to ensure that they are touching all of their bases to ensure a quality final product?

The problem is that everyone has a different take on this process.   Although I’m not any different, but I do have my own process that has worked well for me for some time. My ideal process has six basic steps to it.

  1. Iterate
  2. Design
  3. Develop
  4. QA
  5. Implement
  6. Back to step 1.

Look a lot like a basic design process? That’s because it really is. Almost by definition, the job of a UX Engineer is to provide the right kind of support to the development/QA/leadership teams at different steps along the way. Here’s a quick rundown of how I approach each of these steps.

1. Iterate

Nothing’s better than a little brainstorming. I always try to spend a few hours in the morning gathering ideas from different sources, even if they’re ideas for something that isn’t a current project or doesn’t yet exist within our ecosystem. I’ll cruise Twitter, read UI/UX blogs, check out Dribbble, and spend a little bit of time doodling ideas on my whiteboard. Very often I’ll find myself dragging in a developer, manager, marketeer, or some other team member into my cube to give me feedback or thoughts on a piece I’ve frankensteined on my whiteboard. Often I’m creating a steaming load of poo that can’t be used, but every now and then we come up with an idea good enough with which to move forward.

This is in addition to being the one who’s dragged into different meetings to provide my two cents. Very often the life of a UX Engineer revolves around giving spot opinions on topics with little or no notice. This is a skill to hone, but one you’ll get better at as time goes on.

Also key in this process is getting an idea of the business needs behind a particular project. Speaking with business owners about the business needs behind projects in the works really helps me get an understanding of what a particular project is supposed to accomplish.

All sorts of other things could go on here. Building user personas. Gathering/examining analytics to determine pain points or deadends. Direct interaction with users, feedback forms, scripted user testing. All of these methods could help me get an idea of what needs to be done next in our product.

2. Design

Once I’ve been drawn into a particular project, I’ll begin the design process.

The first step is always to build a Low-Fidelity (LoFi) design that can be easily changed or adjusted as new feedback comes in.  This can be doing anything from more whiteboarding sessions to sitting down with graph paper and hand drawing something out.  As more information comes in, changing these types of designs is easy and inexpensive from a manpower perspective.

Once I feel confident that I have all of the business requirements figured out and have a good working LoFi prototype, I’ll continue on by firing up Photoshop or a prototyper tool like JustInMind to do something more in-depth (known as a HiFi Design).

My goal is usually to have a very solid, interactive design ready for my developers by the time we get to anything approaching backlog grooming (or similar ritual in non-Kanban environemtns). Not only does this ensure that I’ve given my developers a great chance at success as they can visualize a design that may otherwise be a bit more abstract, but it also puts to rest a lot of the design bickering that often happens among the development team.

It’s important to note that I also prefer to do a fair bit of user testing at this point. I’ll bring in business partners to review designs, bring in clients to do A/B testing or provide feedback on mocked up screens, and if I’m able to get a really good mockup created, maybe even do some scripted user testing to ensure that my designs are intuitive.

In reality, probably 95% of my active work is done by the time I’m handing this piece off to my developers. My role shifts drastically from design to support and testing in the last three steps.

3. Develop

During the development process, I should ideally be supporting our developers by answering questions and providing clarity on my designs.  This is far less of a hands-on approach than in steps 1 and 2.

I also like to have a demo presented for me by the developers so I can confirm that look, feel, and functionality mirror my designs and business requirements before the project is handed off to a quality assurance team as any changes made post-handoff are much more expensive to make.

4. QA

As development comes to a close and the project is handed off to QA, support remains my main objective.  I also prefer to get one final demo prior to deployment to ensure all is ready-to-go.

5. Implement

Post-implementation, I’ll usually help by checking to ensure that the deployed design looks, feels, and functions correctly on a basic level.  I’ll also do user testing as soon as possible after deployment to get good feedback and lead…

6. Back to step 1.

In an iterative world, creation is, quite literally, the alpha and the omega. Nothing is ever truly “finished.” As soon as a feature is rolled out, I’ll begin collecting and analyzing data to see how we can make it better. I’ll cruise Twitter, read UI/UX blogs, check out Dribbble, and spend a little bit of time doodling ideas on my whiteboard.

Inevitably, there’s always something to do.

I’m sure my process is very different from others, especially considering my industry and team. Ask 10 different UX professionals, and you’ll get 10 different answers on this question.

What is your baseline UX process?

One thought on “Running the Baseline: The Basic User Experience Process”

Leave a Reply

Your email address will not be published. Required fields are marked *