My UX process
Generally, I would first start with the definition of requirements through Empathising with the users, Defining the pain points, Ideating a possible solution based on a hypothesis, creating a prototype and testing it with users with multiple iterations on each of this process.
1. Empathize
Once the definition of requirements is clear I would create a research plan to think about what do I want to find out? and I would divide the questions into methods or artifacts that define the best context for each type:
1.1 My observations and notes
The current structure, navigation, and designs of the current product
1.2 Usability method / ethno-observations
How people currently use it?
1.3 User interviews/surveys
- What are the main pain problems the users have?
- What are we solving?
- What are the objectives the users want to achieve?
- If people would find a valuable feature to add.
- In what scenario they would need to use this feature.
- Would it need to be adopted by users with several profiles?
- How are they interacting with in different countries
1.4 Benchmarking / Competitive analysis
Are there other platforms that offer these features? how do they do it?
Who can I get this information from?
Potential users, gender, age, and technological level to be considered.
How can I reach them?
I would reach the users that have been involved in using these tools in the area or country of the product’s market.
2. Definition
I would gather all of my findings from the empathize phase and start to make sense of them: what difficulties and barriers are the users coming up against? What patterns do I observe? What is the big user problem that the teams need to solve? By the end of the define phase, I would have a clear problem statement.
I would also create a Persona so I could empathize with him/her during the process, this would include his/her goals and needs, frustrations, motivations and any relevant information that would help me to solve their issues.
3. Ideation
With a solid understanding of the users and a clear problem statement in mind, it’s time to start working on potential solutions. The third phase in the Design Thinking process is where creativity happens.
That being said, we have to bear in mind that content is one of the most important parts of a web or app. Without it, no matter how much “beautiful” the design is, we have nothing to communicate to the user. In this way, the user can easily find what they are looking for. In addition, it will also allow us to easily add new features and scale the product.
First, I would make an inventory. The first step is to identify everything we want to include in the project, based on the content and functionalities we want to offer.
To decide what to include I would rely on the research and knowledge I have obtained about users, but also on the current platform, on the demands or expectations of the company and on what the competition is offering (benchmarking) and, of course, in the term and budget.
Second, I would group the cards. The second step is to establish relationships between the inventoried items, to decide which ones should be grouped in the architecture within the different sections or menus, and also within each page.
The key is to discover where users expect to find the items when they navigate in pursuit of a goal. A good technique to answer these questions is to ask the users to do a card sorting.
Third, I would define the map. The third step is to reflect all the previous data on a map. This will allow me to see the relationships and groupings established between the contents.
Sometimes it will be necessary to rename some categories or even allow access to some sections from different categories.
4. Prototype
At this point, it is all about experimentation and turning ideas into tangible products. It is a low version of the product which incorporates the potential solutions identified in the research stage. This step is key in putting each solution to test and detect any restrictions and imperfections.
Throughout the prototype stage, the proposed solutions may be accepted, improved, redesigned or rejected depending on how they are managed in the prototype. Every prototype will have a testing phase involved, described in the Testing section.
Paper prototypes are ideal to rapidly test broad concepts. They’re quick, cheap, and highly collaborative; they don’t require advanced design skills, so different people from different teams can easily be involved. They are best kept to the very early stages when I need to quickly explore a variety of broader ideas or concepts.
I would move onto hi-fidelity prototypes once I have a good idea of what I am going to build. They’ll help me to fine-tune the design by including all the visual components, interactive elements, and content that will be featured on the final product.
Then I would incorporate the design into a clickable prototype which is hugely beneficial when it comes to user testing.
5. Testing
Putting the user at the heart of the process requires to test the designs on real users. It is extremely helpful to test the ideas, the concepts, the paper prototypes, and the final design at all times. This will help me to for example iterate an idea when the user does not understand it, or to change the architecture if the users do not complete a task where they need to find a category on the menu.
Setting a clear objective will help me to build the right kind of prototype and choose the most appropriate user testing method.
For example, in the early stages of the process, testing will help me to get feedback on the initial ideas. At this point, I would use paper prototypes to test out a concept.
As the design starts to take shape, I would move into digital prototypes. Low and mid-fidelity clickable prototypes can be used to test things like layout and information architecture, without distracting the user with too many visuals.
In the end, I would test the overall usability of the product with high-fidelity, fully functional digital prototypes that look and behave just like the real product.
Another crucial aspect of user testing is recruiting the right participants and gather all the necessary equipment to test it properly.
During the testing, I can be in another room analyzing and commenting with a team of fellow UXers or I can be in the same room as the users while they test the prototype, this way I would be able to control the testing environment and keep distractions to a minimum and also I can directly observe the user. This permits to being able to see facial expressions, body language, and any verbal comment the user makes as they interact with the product.
For abroad members I would do a remote user testing, it offers a less expensive and convenient alternative, but on the other hand, I will have little control over the user’s testing environment.
Throughout each user test, I would need to document the findings. Generally, I do this task with one note-taker colleague. A thorough record of each test would be ideal to analyze my observations and compare the results of each session to set the next steps.
In conclusion, depending on the stage of the process, testing will reveal unexpected insights. By gathering first-hand user feedback, I can make informed design decisions—improving user satisfaction in the long run.
Very thoughtful read! Thank you for putting it together. It’s definitely valuable to get some perspective on why stuff can be so hard.