Newbie Question - What IS the baseline UX Process?


#1

I know already that people are shouting at the computer screen “there isn’t just one process, it depends!” Okay, I get that, have heard it many times, but still there should be some kind of officially recognized baseline process that most UX professionals at least begin with and maybe make adjustments to as needed.

I did a quick scan of the UXPA web site but didn’t find anything.

And to make my question more succinct - what is the recommended baseline process for Web sites and mobile apps?

Also, my feeling is that in order to be user centered the process basically has to be iterative - meaning developed in multiple phases per continuing user feedback (not waterfall methodology) - would everyone agree with that or not?


#2

There isn’t just one process, it depends!

Okay, now that I got that out of my system, your baseline process is a question that always comes up interviews. Having some idea of how to answer this question tells your perspective employer about you as a UX professional, so I can’t blame you at all for wanting a good feel for the flow.

For me, my ideal process is as follows:

  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. This can be doing anything from more whiteboarding sessions to sitting down with graph paper and hand drawing something out to firing up Photoshop or a prototyper tool like JustInMind to do something more in-depth. A bit of this depends on how knowledgeable I am about the end goals of a project, but as my understanding of the potential needs of a gel my design will inevitably flesh itself out. My goal is usually to have a very solid, interactive design ready for my developers by backlog grooming (we work in an Agile Kanban environment). 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 used to happen among the development team.

It’s important to note that I’m also doing 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 this point. My role shifts drastically from design to support and testing in the last three steps.

3. Develop
4. QA
5. Implement

At this point, my goal is to provide proper support to our development, QA, and implementation teams. This might involve answering questions from the developers, assisting QA with understanding requirements so they can write effective test cases, or taking a look at the product post-deployment to ensure what was developed is actually what made it to production. While I’m mostly just one of many helping hands at this point, I like that I can still add some value.

I may also do some additional user testing here, which mostly consists of scripted user testing in our test environment with a handful of trusted clients.

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. I hope this gives you a bit of insight about my base process, and helps guide you in the direction of new topics and approaches to explore. Happy hunting!


#3

Hey @dougcollins, thanks SO much for taking the time to share your process with me - it’s really appreciated! After several days of research I now have a much better handle on the basic steps and the list of potential activities that could be part of a UX process. It’s an ongoing education for me with much more learning ahead but its becoming slightly less vague - now if everyone could agree to use the same terminology I would be over the moon, ha ha!