Abstract Wikipedia/Updates/2023-01-11

◀

Abstract Wikipedia Updates

▶

Sandy's goodbye letter: On design

Hi Everyone! I am today’s guest newsletter-writer, Sandy.

For the past 6 months, I’ve co-owned UX Design and Research (alongside Amin Al Hazwani) for Abstract Wikipedia and would love to share my thoughts and experiences with you.

Background

You may have heard from previous newsletters a bit about the Google.org fellowship. The Fellowship lets Googlers complete up to six months of full-time pro bono work to accelerate the social impact of Google.org’s top partners, one of which is Wikipedia.

It has been a great experience to be able to partner with Wikifunctions, knowing how much this incredible team is contributing to a world in which every single human being can freely share in the sum of all knowledge.

So, what is it like to be a UX Researcher/Designer at Wikifunctions? Day to day includes high level things, like conducting user research to assess the needs and goals of users, crafting user journeys, helping set a long-term vision for the product from a user-centric lens, all the way down to designing development-ready design assets (mockups, prototypes) and prioritizing design tasks, and facilitating implementation.

Starting with Research

Early in the fellowship, I set out to expand on the team’s work on the target audience for launch, and their mental models.

I conducted User Research with Non-Developers — people from various industries who may write code but don't identify as engineers. A lot of my work has been centered around this user group as ultimately, the hope for Wikifunctions (which can be highly technically complex) is to be more widely usable and accessible.

High level findings from the study:

• The participants interviewed shared a tendency to use libraries of existing code, where the work of creating functions has already been done by someone else. They may tweak or make edits, and it can be frustrating to find exactly what they need. We wondered, if creating functions was easier than writing code, would that remove the barrier or would they still hesitate to create their own functions?
• We also found that It was only after seeing several examples of what Wikifunctions can do, that participants understood and were able to apply ideas for their own field of expertise.

Design Sprinting

I shared these findings with the team at our offsite in Zurich during a day-long Design Sprint, (which was based off of a shortened version of the Google Ventures design sprint format) - it was productive and truly- so much fun- to engage with engineers and product managers and all types of team members in sketching and ideating together.

These study and sprint findings informed several design changes and proposals for Wikifunctions, which aligned with a lot of the hopes the team had already expressed for improving ease of use.

Here are a few examples of the new features and proposals:

New users and Understanding Functions

User Goal: As someone who is new to Wikifunctions, I need a way to understand what functions are, how to write them and how to use them, so that I can be an engaged member of the Wikifunctions community.

Ways to address that goal:

• Giving users a chance to engage quickly with a function on the homepage to get a better sense of how it works at a glance, for example, this "function of the day" (Rather than create an entirely different experience for new users, we found it preferable to integrate text and features that could be beneficial and interesting to both new and well-versed users.)

A main page mockup design showing a "function of the day"

• Helper text, that provides assistance to those who are looking for it, to explain what is required for each field when creating a function

A screenshot of the helper text for creating a new function at Wikifunctions

A screenshot of the helper text for a new function named Add

• Creating a space for lengthier explanations of complex concepts - like, “What is a type? And how can I determine which type to choose- when defining a function?”

A screenshot of the helper text for lengthier explanations of complex concepts

Discovering relevant functions

User Goal: I need a way to discover relevant functions, so that I can find an answer to my query and know that I am not duplicating work.

Ways to address that goal:

• Highlighting several categories on the homepage that we know are of interest to certain groups, for example, "functions for editing wikipedia" and "functions for natural language" and "functions to get started with"... These lists (and new ones!) would be editable and contributed to by the community.

A mockup of a "similar functions groups" design idea for Wikifunctions

• On the function page, showing related functions- as a way of easily jumping from one relevant function to another, and to get a sense of what functions are out there in that particular space so as not to duplicate a function that already exists.

A mockup of a "related functions" design idea for Wikifunctions

Implementation

Another huge part of my role and responsibilities has been working closely with the development team to implement all these features and ideas. Together, designers and engineers go through with a fine toothed comb and refine specific interactions. The one thing you can count on is: discovering use cases or roadblocks you didn’t anticipate! We also depend on close collaboration with the design systems team — whose responsibility it is to ensure UI consistency across Wikimedia projects.

A screenshot of various test cases when using the WikiLambda interface

Finally, a meta-goal I’d like to speak to is:

Sharing design work with the public

It’s important for not just Wikifunctions but for the organization as a whole to keep the public updated on how we are thinking about this project from a design perspective, and invite the community (you all!) into the conversation to provide clarity on what a product should be.

Hopefully this newsletter is another step towards that goal!

You can also take a look at our page here and add your name if you would like to contribute to future user research.

Thank you for reading!

---

Public NLG workstream meeting on Tuesday

Reminder: next week on Tuesday, we will host the first public meeting of the natural language generation workstream. The workstream includes the volunteers and staff that have been working together in the last few months on exploring the natural language generation work that will be necessary for Abstract Wikipedia. Everyone is invited to join. The meeting will be on Tuesday, January 17, 2023, 16:30-17:30 UTC and you can join on Jitsi on the following link: https://meet.jit.si/AWVolunteersCorner

This week’s volunteer corner on Monday, January 9, had seven volunteers joining. We had a lively discussion about the project, and we remain amazed by the volunteer developers and their contributions to our codebase. Thanks everyone for attending!