My UX Design Process

MY 6-step process

Step 1. Research

Step 2. Concept

Step 3. Validate

Step 4. Design

Step 5. Test

Step 6. Release (Bug fixes)

Research: The Challenge

Understand what you're up against.

The Product:

When first starting, you have to understand what it is. Who uses it, what are all the parts, and how do they relate. Also, are there similar products? What do they do?

The Users:

Who are the users, why are they using it, how do they use it, and what do they have to say about it.

The Problems:

What are these problems, why are they problems, to whom are these problems, when do they arise, and finally, what is their priority.

Research: The Approach

Document the findings to share with others.

The fidelity of the documentation is usually reflective of the time available.

The Product:

Document all findings about the product. Using the appropriate UX document for each. Sitemap, site flow diagram, features/functions list). Search for comparative products, and pros/cons for them. Search for competitive products or services.

The Users:

I feel interviewing users is the most vital process in retrieving information from people. The intimacy of sitting down and letting them tell their story is the most honest way to understand the thoughts or feelings regarding an experience.

The Problems:

Create a list of customer pain points, and record where and when they occur. Grade them based on how important to the user they were. This could be annotated screen capture of the current product.

Concept: The Challenge

Take what was learned and formulate visual designs

The Product:

This is where it gets tricky.

Create a design that takes what was learned from the research stage and incorporate it into the concept designs.

The Users:

All the users need to be considered. For example, a homepage may have a number of states, to a number of users.

The Problems:

Some problems require changes that are project wide, other's are more localized. These may be business related, or development related (APIs, Database support, etc...). Some may require sign-off from other departments, etc...

Concept: The Approach

Start with the least amount of variables, and gradually add more.

The number of designs should reflect the number of major templates needed.

The Product:

Start with a simple sitemap. Create designs with only the minimum necessary pieces. Using your trusty usability guidelines (iOS / Android), and your experience from previous successes and failures to guide your decisions.

I use color only where needed. I use neutral grays, and keep it rough. This helps communicate that this is a concept, and not fixed in stone. This also cuts time spent working on individual screens, freeing up time to have all major screens done for the next steps.

The neutral colors also avoid conflicting creative opinions that don't need to be considered at this early stage.

The Users:

Based on the initial research, I create documents that communicate the results (with as little bias as possible). Visual representations of personas. Journey maps of the current state of the product, noting emotional mood based on the interviews and research.

The Problems:

Create a list of customer pain points, and record where and when they occur. Document for sharing with appropriate document. (Spreadsheet, annotated wireframes, Journey maps, etc...).

Don't forget to TALK TO OTHER DEPARTMENTS. This is where having a (lite) background in application development comes in handy. Encourage an open dialog.

Validate: The Challenge

Sharing designs that have not answered all the problems.

The Product:

Showing a design that may or may not be what others have in mind.

The Users:

Each user may see different things. This means different people in the room will be looking at the designs from their own perspective, and responsibilities.

The Problems:

Not all the problems can be solved or should be addressed at this point. Any decision made at this early stage will have a ripple affect.

Validate: The Approach

Get it wrong early rather than wrong late.

"Getting something big wrong early is understandable, and acceptable. Get something big wrong late is a disaster you DO NOT want to happen, and you DO want to catch as early as possible."

The Product:

Present the designs first with other designers (if available), co-workers with knowledge on the project, your project manager. Other UX designers (if allowable).

The Users:

Having done your due diligence, you can start making projections in your journey map, personas. At this point it should be very quick and lite work.

The Problems:

In the designs are assumptions on solutions to problems. They're not solutions just yet. Axure is great a creating exportable interactive prototypes. Grab someone around and let them have a go at it.

Design: The Challenge

Time available is shortened, work to do is increased.

The Product:

Higher fidelity wireframes require more time, and more details means running into harder to spot problems. More screens means more opportunities for inconsistencies

The Users:

Users will have opinions on the designs they're seeing. Many people will have opinions. Because there is more to have an opinion about.

The Problems:

Solutions to problems may conflict with each other. Although some solutions may cancel each other out. You don't know until you've worked them through from start to finish, considering every tangent and offshoot.

New additions require an understanding and analysis as to how it fits into the products ecosystem.

For example. Creating a grid that can only hold 5 columns, and adding 3 more. This is a major change. If a database has been created and it populated the site with only 5 columns and is being fed 8. This may cause errors.

This also impact the design. Suddenly it is a much wider screen and another design challenge to solve. Time tables need updating, and project road maps needs updating. Did you give someone a time when this screen would be done?

Design: The Approach

Keep the train moving in the right direction.

"This is where your extra time and effort starts to pay off."

The Product:

Because you search high and low for problems, and solutions, because you've organized your files, layers, and notes. You increamentally saved versions of all your work, you have some flexibility.

The Users:

Although someone successfully completed a task before, it's not to say they will be able to now. It's important to not drastically change the design. All your user research will come in handy when pushing back on change requests.

The Problems:

If new features are introduced, push back and see if this needs to be done in this release. Get updated estimates from development teams, project managers. If it just a localized change, it shouldnt be a problem. Wireframes will need to be updated. Keeping the documentation in sync is important part of your responsibilities. (Again, your tidy work saves the day.)

Test: The Challenge

Your fancy designs into the real-world like environment.

The Product:

This has the possibility to bring up big issues that were hiding in the chaos. New features may be introduced by the client/stakeholder, maybe the user. Perhaps a competitor just released their new version and the landscape has shifted.

The Users:

The users have more screens to explore so there will be more feedback to consider.

The Problems:

Feedback will result in more problems and changes.

Test: The Approach

Stay consistent, review previous tests.

The Product

Iterative prototypes should give a lot useful information. Keeping everything synced up is the key.

The Users:

Given the feedback, and the looming deadline, these issues need to be prioritized.

The Problems:

The only way to solve all the issues and work that needs to get done is prioritize and spend more hours on the project. 12 hour days are not unusual when the release day is looming.

QA should be coming back to you with questions. Be available and knowledgable in your answers. Seek to understand in order to be understood. Your annotations in your wires will hopefully answer most of these.

Release: The Challenge

It's not perfect.

The Product:

Last minute changes will come in. Marketing department wants to put ads in all of a sudden. The client doesn't like the rounded edges in the buttons.

The Users:

Users have questions on additional features.

The Problems:

There'll be a flood of support emails and calls asking how they forgot their username and password.

Test: The Approach

Time to start on 1.1

The Product

It isn't perfect, but major roadblocks have been addressed in previous steps. You've designed for the possibility of additional features (within reason).

The Users:

Users want more features. See what can be done with the current version. Can it already do what they're asking?

The Problems:

There will always be problems. The goal is a product with the least MAJOR problems.