The missing piece
It took me the past three months, albeit with breaks in between, to finally complete the User Experience Research and Design specialisation from Coursera. I’ve written about the limitations of online courses and their advantages, but nothing had prepared me for the last part of this specialisation. The course UX Capstone is divided into six weeks, with each week requiring a research and design task that is, essentially, the final project of each of the previous courses.
Since I had to develop a project from idea to prototype, I’ve decided to re-imagine the computer building/modding experience. This project would let users browse all the different computer components, just like PcPartPicker or any online vendor, while helping the users make informed decisions by explaining each component’s function and what specifications to look for when browsing all the available models.
After one user needs finding study, two usability tests and several design processes in between, the resulting prototype was not particularly mind-blowing, but it revealed many insights. On both user testing sessions, users mostly followed the experience patterns they are used to and avoided any extra cognitive work. No matter what new feature or didactic materials I added to each screen, unless that information was presented at the exact moment that users got stuck, it would generally get ignored. Most of the times, users laser-focused on the buttons/actions that would match what they were looking for, click and proceed.
Other granular findings could have improved certain individuals' experience, but nothing stood out more than the search component. In a small population of just four interviewees, in one task to find out the highest performance CPU, half the users attemped to use semantic search while the other half browsed the website because they didn’t know which keyword to use in their search query. This observation leads me to believe that some users might not want to learn more about components as I expected. They just need better search tools.
Research to Software
Completing a specialisation like this and having a broader sense of product development also forces you to reconsider your battles as an engineer. Much of the stuff that we fight so hard for, or are very picky with our software peers, will likely go unnoticed by our users. On the other hand, small UI and UX tweaks can significantly impact how users use the app and be the difference between using a feature or not.
Furthermore, if you plan to invest time in a new side project, I would recommend spending a week researching before you start developing software. The following research and design processes can help you focus on what matters and flesh out any unnecessary features that you might think of including, and thus wasting time, in your software MVP (minimum viable product):
- Do a competitor analysis to see what others do well and note down the industry standards and best practices. Create a list of opportunities that your idea could explore.
- Do a user needs analysis to understand your users' needs and current practices related to your project’s problem. Interview users, summarise quotes, opinions and suggestions in the form of insights and define some design goals for your prototype.
- Create a set of personas and scenarios to represent your users and their key tasks. Highlight differences among your user population that will be important for your design to support.
- Sketch and ideate.
- Build a low-fidelity prototype. You could use wireframes to sketch and imagine how the prototype’s navigation would fulfil your design goals. Alternatively, you can do a paper prototype as well.
- Do a micro-usability test with a few of your target population’s users to have the first round of feedback on your solution.
- Iterate on the prototype and build a med-fi prototype with all the learning gathered from the micro usability test. This time, work on previously ignored design details but keep in mind the platform you are targetting. Skip fonts, colours, or animations for now.
- Apply the UI/UX heuristics evaluation to your design to find out critical usability flaws and apply them in your next design iteration.
- Do a thorough usability testing with the main flows that you would like users to accomplish and implement the learnings to finalise the experience.
- Iterate on the design and turn it into a hi-fi prototype to make it more appealing and closer to the final product.
Remember that during software development, you might need to reassess your prototype and keep iterating from time to time, as some visual components might not work as you initially expected. Having to adjust the design for each specific platform (ios, android, web) you are targeting is also a common practice.
Finally, it is important to stress that the previous ten steps do not fully represent what professional research and design teams do in a workplace setting. These certainly are some of the methods used, but the time they are used, the detail or the processes themselves, highly depend on what you are trying to achieve. If all you want is to improve a feature of your existing application or to find out which variant of your proposed solutions your users prefer, you will have to adopt a different set of methods.
Revisiting MonzoPrep
In 2019 I worked on a side project called monzoPrep to prepare myself for upcoming interviews as an android developer. Looking back at the solution, I’ve noticed that I’ve merely done a low-fidelity prototype (step 5) and a high fidelity prototype (step 10) immediately after defining the user stories.
Skipping most research steps was okay because the side project’s goal was to demonstrate my technical skill, explore new software techniques, and not research a proper solution to medical insurance in a banking app. However, in a real-world scenario, by skipping most of the research and prototyping stages, I would risk building something that nobody would use. That wouldn’t fulfil any users needs.
As engineers, we tend to get excited with how things work and how to build them, but what we build and why is just as important, if not more. It is a tremendous waste of energy, time and money to create something that nobody will use in the end, so before you build something, invest a few days studying your users' needs, how they interact with other products and why. You will be surprised to find out that a few days of research might end up saving months of wasted work.