How to compile a UX Case Study

When it comes to designing a product, every little factor that contributes to it’s design should be taken into account. Our UX Designer tells you the steps to follow to bring out some of your best designs.

Authored by Swetha Suresh

Usually when I am given a product to design I follow a three phased process. I start with Discovery which would inform the Design and then find ways and means to Validate the design. I take a very similar approach when it comes to preparing a case study of a product.

First step would be to break down the product and explore it for an in-depth understanding of its core functionalities. The core functionalities give away the product’s intent and unwraps the target audience it was built for.

The second step would be to dive into the design and see how the design contributes towards the product’s intent and how it communicates the intent with the target audience.

Finally the third step, what better way to validate the design than to interact with the product or watch someone from the target audience use the product! Critiquing the product through user testing helps in finding flaws and loopholes that can be fixed to make it a better product.

I decided to make a framework, which would essentially be a set of questions or steps that would guide any designer in compiling a case study. Let’s get started!

DISCOVERY

• What was the story behind the start of the project?
• Who is your project focusing on?
• Who are the target audience or user groups for the project?
• What is the problem? List the target audience’s pain-points.
• Document the research - Primary and Secondary, Qualitative/Quantitative etc.
• How was the research carried out? Which tool or techniques were used and why?
• How did the research define the business goals and the user goals?
• Include the persona to better inform the reader about the target audience
• How does the product solve the problem? Cross check with the list of pain-points of the target audience to check if the product meets each point with a solution
• Compare the product with other products in the market that solve similar or the same problem. Recognize their approach and how it is similar or different to the approach that you have taken. This will contribute to your learning curve

DESIGN AND VALIDATION

As designers we are essentially story tellers and presenting a solution in a neat bow tie is what is expected of us. The only way to do this is to iterate till we reach a solution that satisfies the business goals and also the user’s goals. I cannot stress enough how important it is to document all the iterations. The only thing constant in design is change. If there are no iterative changes and if every change does not take the design one step forward then the design will not reach it’s full potential.

• Document the iterative:
• Site map
• User Flows
• Wireframes
• What were the reasons for these iterations and your thought process behind choosing that approach?
• Include the low-fidelity prototypes and document how user testing was carried out using the low-fidelity prototype
• What is the style guide used and what are the reasons for choosing the colour palette and the visual vocabulary?
• Observe if consistency is maintained in the product
• Include the High-fidelity prototypes and document how was user testing carried out using the high-fidelity prototype
• Finally present the product after showcasing the iterative process

In the end its nice to include your key takeaways from the project and the process. An important point to keep in mind is to present the entire study as a story. That adds to the readers’ experience and makes it pleasant. After all we are designers, we need to make it pleasant to the eye and the mind. In this context taking a very pictorial route will communicate the intent of the study better.

Compiling a case study is not limited to the above mentioned steps. Every product is different and so is every designer. The method can be modified to suite any project. And if you require any help in that space, give us a ring!

This article first appeared on Skcript.