This week's newsletter embeds quite a few images. The on-wiki version might
be easier to read or break less:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-01-11
----
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
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-04-12>.
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
<https://docs.google.com/presentation/d/1frcJmw9GBBNUc54wV05Gxm4uboN_PWIZ_U8GLt6TdrA/edit#slide=id.g16fe425cb37_0_252>
—
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
<https://docs.google.com/presentation/d/1Blg8gu1oplwNDEq-gZNwce5zWiFtCzrsFUPwUD1aEsY/edit?usp=sharing>,
(which was based off of a shortened version of the Google Ventures design
sprint format <http://www.gv.com/sprint/>) - 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.)
[image: A main page mockup design showing a "function of the day"]
<https://meta.wikimedia.org/wiki/File:WikiLambda_main_page_mockup_Function_of_the_day.png>
- Helper text, that provides assistance to those who are looking for it,
to explain what is required for each field when creating a function
[image: A screenshot of the helper text for creating a new function at
Wikifunctions]
<https://meta.wikimedia.org/wiki/File:WikiLambda_helper_text_Create_function.png>
[image: A screenshot of the helper text for a new function named Add]
<https://meta.wikimedia.org/wiki/File:WikiLambda_helper_text_Add_function.png>
- 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?”
[image: A screenshot of the helper text for lengthier explanations of
complex concepts]
<https://meta.wikimedia.org/wiki/File:WikiLambda_helper_text_for_complex_concepts.png>
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.
[image: A mockup of a "similar functions groups" design idea for
Wikifunctions]
<https://meta.wikimedia.org/wiki/File:Wikifunctions_design_idea_grouping_functions.png>
- 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.
[image: A mockup of a "related functions" design idea for Wikifunctions]
<https://meta.wikimedia.org/wiki/File:Wikifunctions_design_idea_related_functions.png>
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
<https://www.mediawiki.org/wiki/Design_Systems_Team> — whose responsibility
it is to ensure UI consistency across Wikimedia projects.
[image: A screenshot of various test cases when using the WikiLambda
interface]
<https://meta.wikimedia.org/wiki/File:WikiLambda_design_nuances_using_Codex.png>
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
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Design> 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!