top of page

Make your report user-oriented.

As a researcher, you know that your work mostly revolves around the user. You spend a lot of your time understanding user needs and goals, and then using those insights to make design decisions. This approach should also apply to creating your research report for stakeholders. Additionally, while presenting the report, you should not only consider the expectations of the stakeholders, but also what they are accountable for.

The recommendations should be strategic and actionable.

You normally create a list of recommendations for the research report. It’s good to keep them as a record, but don’t include all of them in the final report. You should present only the top 3 recommendations that are most strategic and actionable. Additionally support these recommendations with data and evidence. Make sure stakeholders know that there are more, but these are the top recommendations based on viability, feasibility and desirability.

Record the details, but present the highlights.

The idea that a design research report should be something really comprehensive, is not so relevant to the modern world. Your stakeholders belong to a world that is ever changing and getting faster. So your report needs to be designed in accordance with this pace. It should be brief and focused on what actions will have the most impact. Consider adding cost, user impact and business value to the recommendations.

Align with the stakeholders.

You should always try to quantify the risk. In case you have a stakeholder with a skeptical nature, you will need to design recommendations in a way that quantifies the risk in doing and not doing the recommendation. That is why it’s important to be clear on what your stakeholder accountabilities are.

Present recommendations with confidence.

After you have used your skills in preparing the report, present it with confidence. Your recommendations should be presented like a viewpoint, and not opinion. Your report is not showing personal likes. It is based on expertise, research, client insights and the relevant data.

Listen to your stakeholders' feedback.

When you have presented the research report and recommendations, don’t expect stakeholders to always agree with you. They may have solid business reasons behind going a different direction or choosing to prioritize some recommendations over others. The key is to listen and ask questions. It’s also important to consider opportunities for additional research or deep diving on specific elements.

Record everything for future rethinking.

Now if the stakeholder is not convinced to go ahead with a recommendation, it’s time to go back to the detailed study that you had done. Remember to save and document everything (transcripts, recordings, notes etc.), but it’s not necessary to include them in the final report. The documented information can help you or other researchers to find alternative solutions if the recommendations or plan is not agreed upon or insights are challenged.

Share your recommendations.

Try to make recommendations as shareable as possible. The more comprehensible findings are, the better the chance of them being considered and appreciated.


In conclusion you have to be confident and concise while designing a research report for the stakeholders. Be user-oriented while making the report, but also flexible toward your stakeholders while presenting it. Achieving this balance is the key to your success as a UX researcher

Designing Research Reports Stakeholders Will Appreciate

Writer's pictureBalwinder Singh
Nov 8, 20234 min read

Guide to Measuring Twice, Design Once

Right from the time you step into this field, be an active learner and grab knowledge wherever you can, be it your fellow designers, mentors or even Google. With each experience, you will learn and eventually develop a system that enables you to be efficient. Over the years I have learned a lot from my senior colleagues and designer managers on how to manage time and work.

While working on any project, time is often more valuable than money. My seniors and mentors always focused on time-management and utilized it as a currency. Here is a brief summarization of the knowledge besotted on to me:

Gather requirements well in advance

Collect necessary inputs from your stakeholders and users at the very initial stage of the process. This will give you enough time to define the problems and objectives. Every hour you spend here will save you 2-3 hours in the next phase. The key is understanding how success will be measured.

Ask questions from the perspective of each group. As an example ask:

  • Business: How does your website or product enable clients? Where are the current issues? What would be valuable? Who are your top competitors?

  • Technical: What are the current and future capabilities of the platform? What are the technical limitations and why?

  • Clients: Why did you choose this company over a competitor? We're there any challenges onboarding or using the platform? What would make you leave for a competitor?

The more you know about these groups' needs and requirements the more impactful your solutions will be. Everything you design should solve a problem and/or enhance the experience.

Start with some inspiration and paper

This will help avoid duplicating your previous designs. Naturally, you will end up getting stuck on designs you have either seen or worked on earlier. It may happen without you even realizing it. Start by getting some inspiration conceptually from sites like Dribbble or Behance, but also have real-world examples up your sleeves. I was taught to look at adjacent industries. If I were doing finance, I would look at health apps. Both finance and health apps use data and often require users to do quick interactions.

To avoid a scenario where you unintentionally imitate your earlier designs, start on paper and let your creativity flow all over the place. While this process might be a bit time-consuming today, it will save you a lot of time tomorrow.

It is okay to repeat successes as some patterns just work! But that doesn't mean they need to look the same too.

Bring everyone along for the ride

Ask your developers to look at the wireframes and user flows you have in mind as soon as you can. Developers have better knowledge and understanding of development feasibility and UI response behaviour. I can’t stress the importance of this, the last thing you want is to share your final designs with stakeholders and then have the development team say, “yeah we can’t do that, or that will take 2-3 times longer.”

Hence, involving them in the initial meetings will prevent going through a number of changes in the future. The alterations in designs are generally due to technological constraints, so be sure to run it through your developers right at the beginning. Don’t be afraid to push back or ask them to come up with alternative solutions.

Bring your stakeholders along for the ride. Show them your initial research and interview notes and insights. Also, share your user flows and low-fidelity wireframes with them. It is important to get early feedback. I was taught that each stage keeps getting more expensive/time-consuming to make changes. “All feedback is good, only bad feedback comes too late.”

The content: chicken or the egg

Only start final designs after you have final or near-final content. I suggest providing a rough draft for the information architecture and wireframes to the writers. I have learned to do wireframe blocking, with a definition that explains the intention of each module or block on the page.

Alternatively, the writer can provide a rough first draft, and you lay this out in low-fidelity wireframes. That way, you can work together to finalize the content based on the objectives of the website or product.

Be mindful of future functionality

Keep the future scalability goals in mind whenever you are designing a product. It will cut down on your time otherwise spent on re-architecting it later. I was taught to wireframe as far into the future as possible then pull back to the MVP.

Alignment over process

Define your process upfront, and try to stick with it. There should be stages of exploration and stages that converge insights. Be flexible as sometimes you might have conflicting input that might require another interview or workshop to align everyone. I can’t stress this enough, everyone needs to feel heard and as participants in the solution.

Ultimately, your goal should be to have a great user experience that brings together the business, technology and the user, and everyone should be clear on what they are building and why. Good luck!

7 views0 comments

Comentarios

bottom of page