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.
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?
Who are the users, why are they using it, how do they use it, and what do they have to say about it.
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.
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.
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.
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
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.
All the users need to be considered. For example, a homepage may have a number of states, to a number of users.
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.
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.
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.
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.
Showing a design that may or may not be what others have in mind.
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.
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."
Present the designs first with other designers (if available), co-workers with knowledge on the project, your project manager. Other UX designers (if allowable).
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.
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.
Higher fidelity wireframes require more time, and more details means running into harder to spot problems. More screens means more opportunities for inconsistencies
Users will have opinions on the designs they're seeing. Many people will have opinions. Because there is more to have an opinion about.
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."
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.
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.
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.
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 have more screens to explore so there will be more feedback to consider.
Feedback will result in more problems and changes.
Test: The Approach
Stay consistent, review previous tests.
Iterative prototypes should give a lot useful information. Keeping everything synced up is the key.
Given the feedback, and the looming deadline, these issues need to be prioritized.
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.
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.
Users have questions on additional features.
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
It isn't perfect, but major roadblocks have been addressed in previous steps. You've designed for the possibility of additional features (within reason).
Users want more features. See what can be done with the current version. Can it already do what they're asking?
There will always be problems. The goal is a product with the least MAJOR problems.