Consistent syntax as a key element for writing reports

When writing a report, keep in mind that your learnings might outlast you: maybe the team won’t have time to fix everything for their next sprint, or perhaps things that aren’t a priority for this quarter could become important for the next. By using consistent syntax to write your learnings, teams will be less likely to rely on you. Yes, this is a good thing because: - It means you won’t create a bottleneck when several teams come to you asking, “What did you mean by…?” or “Do you remember what happened in study X about Y?” - You might not be working at this company anymore for whatever reasons (either because you’re a consultant, a freelancer, were laid off, or just quit) - You’ll want to focus on your next studies Using a consistent writing style in your report will also ease the work of your colleagues and reviewers (managers, mentors, peers): they’ll know where to look and what kind of information they’ll find there. ## Who is interested in your learnings, and why? Besides those in strategic positions who may attend your presentations, consider professionals who might be more directly concerned with your learnings: In a presentation, it’s primarily the titles and prioritizations that will grab attention. Different roles will focus on different aspects of your learnings: - Product Managers will be interested in the overall impact on the product and user experience. - Designers will focus on specific UI elements and interaction patterns that need improvement. - Developers will be concerned with the technical feasibility of implementing suggested changes. - Marketing teams will pay attention to how learnings might affect communication and user acquisition. - Business stakeholders will be interested in how learnings relate to key performance indicators and business goals. Remember, your report needs to cater to these diverse interests while maintaining a clear, consistent structure that allows each group to easily find the information most relevant to them. Now, I’ll share practices on how I approach research learnings. Consider them “learnings about learnings”. Basically, what makes a learning is: 1. A title 2. A qualifier 3. A description 4. A cause 5. A suggestion for improvement ## 1. Writing the title What I am about to say is true for the whole learning’s content, but even more for their titles: use consistent syntax rules. Actually, this advice goes beyond Research stuff: always try to stick to syntax rules when writing things that could be _decontextualized_. Here are two examples of syntax rules: 1. Subject of the observation + Issue (+ Moment ) + UX impact > Ride requests continue to arrive at Cairo’s Uber Bus Drivers 20 to 30 minutes before the end of their shift. These drivers are taking rides that can take them more than an hour over their schedule. **Subject**: The element that poses a problem _Examples: The subscription Call To Action; The search bar; The burger menu; …_ **Issue**: Why _Subject_ is problematic _Examples: Was not used; was not understood; triggered an undesired action; is not perceived as useful; is redundant; …_ **Moment** (Optional): If the problem is only observable at a certain point in the journey or in a particular context _Examples: For subscribers; on the homepage; in the membership area; …_ **UX impact**: What it means for your users and your product. This part is an opportunity to make your title _clickbait-y_. If you think you’ll need the extra attention, do it! _Examples: Thus causing a drop in CSAT; increasing the time on task; triggering a significant drop-out; …_ 2. Who + Where + What + Why > Uber Bus Drivers in Cairo end up working longer than their scheduled shift because they still receive requests 20-30 minutes before their shift ends, which can take more than an hour to complete. (_As reported in this article: [The Power of Insights: A behind-the-scenes look at the new insights platform at Uber](https://medium.com/uber-design/the-power-of-insights-a-behind-the-scenes-look-at-the-new-insights-platform-at-uber-26f85becc2e6)_) By doing so, you’ll make sure that learnings will remain consistent within your company, whoever wrote them. ### **Good practices** - Don’t mention “Participants” in the title. As you should say in your introduction speech: “it’s the product we’re testing, not you”. The design flaw shouldn’t be blamed on one or more participants: the frequency of the problem’s occurrence is already included in the severity of the priority and specified in the “Description” part. 1. “Underlined texts are confused with hyperlinks”: YES 2. “Some participants confused underlined texts with hyperlinks”: NO Mentioning participants in the title leaves room for interpretations like “It’s your recruitment that’s at fault, not our design”. ## 2. Qualifying your learnings To help teams build and prioritize their backlog, you have to agree on properties to qualify your learnings. Think of them as _hashtags_. For instance: - **UX Problems**: - Blocking - Annoying - Distracting - Works fine - **Bug**: a technical bug that has impacted or might have impacted participants’ behaviors - **Feature request**: a feature or improvement that one or more participants brought up during the study. Could be spontaneous or because you had a dedicated time for that in your study - **WOW moment**: A positive event that caught one or more participants off-guard - **Observation**: A singular behavior that is worth mentioning because it was out of the ordinary or might explain some results. I’ve seen some companies use a decision tree to qualify the issues between “blocking”, “annoying”, etc. Might be overkill, but not something to ignore. You can also consider qualifiers about the theme of the issue: `#onboarding`; `#cart`; `#pricing`; `#blog`; … ## 3. Objective descriptions of the problem This is where you’ll describe what you observed during the session. Be concise but above all: stay objective! Link your observations to an estimate of the number of participants affected by the problem. Don’t limit yourself to observations made during the test. If you have scale scores from debriefs, analytics data at your disposal, screenshots / animated gifs / video highlights that give weight to your recommendation, now is the time to include them! **Example description** - Some participants couldn’t find the “Blog” section of the site spontaneously or when asked to do so - Some went to the “News” section - Others typed “Blog” in the site’s search engine, without success - After 30 seconds of searching, one participant stated they would have left the site if they were at home - Not finding the blog section is the primary reason for rating the site as “Below expectations” (debrief questionnaire) - Analytics data indicates a 42% decrease in blog traffic since the site redesign > “I used to come to this site for its blog and now I can’t find it anymore…” > – Participant 03 ### **Good practices** - Break down your observations into bullet points. One point = one fact - Don’t describe the cause of the problem here, only its observation. The cause comes right after! - Unless explicitly mentioned by the participant, we can’t write “The participant thought that…” / “The participant wanted to…”. This would be projecting and potentially biasing the description - If you observed frustration (participant sighing, for example), surprise, joy, or any visible emotional state, don’t hesitate to write it down! - Examples of estimation formulations: - No participant - Few participants (<50% of your sample) - Some participants (>50% of your sample) - All participants - Some use numbers to weight the issue (e.g. _10/12 participants_ .). It works too, but please do not rely on % when dealing with small sample (e.g. _80% of our users were pissed!_) Don’t need to be overdramatic when we’re talking 4 participants out of 5. ## 4. The cause(s) of the observed problem Here, your expertise will be necessary to explain what caused the problem. As with the problem description, you’ll need to be clear and concise to avoid losing your readers. As with writing the title, you shouldn’t leave room to blame the users. It’s the interface that’s at fault! A problem can have multiple causes. **Example of causes** - The architecture of the deployed menu encourages reading from top to bottom starting from the center of the screen, not from left to right. However, the “Blog” section is located outside the burger menu’s tree structure, to its left. - The “purple font on white background” contrast doesn’t highlight the link to the blog - The blog isn’t indexed in the site’s search engine - The burger menu wasn’t used by some participants (see recommendation: “The burger menu wasn’t used on the homepage”) ### **Good practices** - Break down your causes into bullet points. One point = one factor that contributed to the problem - Don’t hesitate to link between problems. They are often interdependent! - Avoid formulations like “there isn’t…”: - It’s a disguised suggestion that implies a solution “there should be…”. Its place is therefore in the next section of your learning - This solution may seem obvious to you, but it may not be the best one ## 5. One or more suggestion(s) for improvement The final step in your writing: lay the first stone in solving the problem you’ve encountered! Be careful though: be concise (always) and stay within your scope: the suggestion is the culmination of the “Problem Description” section and the “Cause(s) of the problem” section. Don’t go off-topic and remain realistic. If you think you lack information to produce a viable suggestion, it’s better not to suggest anything and discuss it with the project team. Making an “out of touch” suggestion will impact your credibility. **Example of suggestions** To make the “Blog” section more accessible, you could consider: - Adding a “Blog” section in the navigation banner on the homepage - Indexing it in the site’s search engine - Making the left block in the burger menu more visible by playing with contrasts (e.g., colored background) or font size ### **Good practices** - Phrase your suggestion in a way that doesn’t order something. It’s a suggestion, not a command - If applicable, prioritize your suggestions from the most plausible to the least plausible or from the simplest to the most complex. Remember, the goal of these suggestions is to provide actionable insights based on your observations and analysis. They should be specific enough to guide the team but flexible enough to allow for further discussion and refinement. Always be open to feedback and collaboration with the project team to find the best solutions.