About this talk
This talk covers the lessons learned from a UX research mentorship led by Prometheus and highlights Victoria Nduka's journey as she transitions from UX design to cloud engineering. Nduka explains the role of Prometheus as an open-source metrics and monitoring system, which serves as a health monitor for software infrastructure, much like a doctor assessing a patient’s health. The mentorship program aimed to understand user expectations around Open Telemetry resource attributes while navigating the unique challenges of collaborating across technical communities. Nduka emphasizes the importance of community engagement and the transparency required to build trust in open-source projects, detailing how effective UX research can lead to substantial impacts and the establishment of a dedicated UX working group within Prometheus. The session concludes with valuable insights for both maintainers and UX contributors in open-source environments.
Full transcript
[music] >> My My topic on my talk for today is going to be talking is going to be covering lessons that I learned and that's the Brighter Community learned from a design mentorship that was done sometime about this time last year. So throughout the throughout the course of this talk we are going to discuss me and I also talk about Prometheus of course the UX research mentorship
that we did cuz that's why we're here. And then the lessons that we learned from from doing that mentorship and then I'll take questions. All right. Who is Victoria Nduka? I am a user experience designer. Um I started out doing UX design sometime in 2022. And to help me gain experience, I began working on open source projects um like Lea five. So I was somewhere here. Then
about last year, yeah, this time last year I decided to make a transition from UX design to a more technical role as a cloud engineer. So now I'm doing UX, open source, and cloud. So you'll see me here, here, or here. And one common thing that I usually do in whatever field I find myself is to write um about the things I'm learning, about the things I
do, and also talk about it. Um this this talk is an is an example of that. So yeah, you can learn more about me on my website um more about me and the work that I do at um victorianduka.com. Um yeah. Prometheus, what is Prometheus? So if you if you go on Google and you search Prometheus, you are most likely going to see this page with an
AI overview that says that Prometheus is a figure in Greek mythology. That's it's not Prometheus that I'm talking in this talk. But if you scroll down a bit, you should see this um Prometheus monitoring system. That's the one I I want you to click. And when you click that, you you it's taking you to this page, the Prometheus homepage. And you see that Prometheus is an open
source metrics and monitoring system. Open open source metrics and monitoring for your systems and services. For my non-technical folks like me who may just be hearing about Prometheus for the first time and have no idea what this is, it's it's essentially Prometheus is essentially a health um monitor for your software and your hardware's uh yeah, infrastructure systems as well. So, um you know the way a doctor
would check your vitals to understand um the symptoms they have and know what's going on in your body, Prometheus does a similar thing. It collects information about your applications so that engineers know what is happening or what's causing a problem with an application. So, Prometheus is more than just a project. It is also a community. It was created in 2012, about 14 years ago. So, that means
in human terms it should be a teenager. Um it is the second most adopted project in the CNCF ecosystem. CNCF stands for Cloud Native Computing Foundation. And the CNCF is an arm of the Linux And Prometheus also participates regularly in the LFX mentorship. The Linux Foundation hosts this yearly mentorship three times each year. And Prometheus is a regular participant in that mentorship program. So, this talk is
going to be about a particular mentorship program that Prometheus did um under the LFX mentorship. So, you would if you check the LFX mentorship platform, you'll see that most of the mentorship that Prometheus has done in the past were were mainly focused on technical stuff. But, for the first time, March last last year, they held the their very first um UX research mentorship, of which I was
selected as um as a mentee. So, the the mentorship was to understand how users expect Prometheus to handle Open Telemetry resource attributes. I'll try not to dive too much into the technical details, but essentially, we are trying to I was I was going to be working at the intersection of two big open source that had some interoperability issues. now you may be wondering, why would like what
motivated me to want to participate in this mentorship or contribute to this community? I have a couple of reasons. And um one of which is the impact that I would make contributing to this project. Prometheus is a big project, and that means that any contributions I made would have wide-reaching impact. Secondly, it's aligned with my career. I was making a transition from you from a UX background
to cloud engineering. So, working on this project would let me move from the known to like something that I I I I knew how to do, which is UX research, to something that I was looking to learn. So, it was a perfect fit for me. And there's learning. Um I like the challenge of doing something that was out of my comfort zone. And then the mentors to
I I looked at the people who were going to be mentoring for the project, and I saw a woman, I a UX researcher, and I also saw a mentee who later moved on to be a mentor in the within the community. So, and these are things that is one thing like it's I I I I know I don't speak myself alone, and I'm sure maybe a couple
of other people feel this way. When you want to when you're coming into a com- community for the first time, these are the things that I usually look out for. If there is diversity, if there are people like me who are already doing well within the community, then I'll be more motivated to join and make my own contributions, knowing that if like like there is the possibility
that I can grow in this community. And [clears throat] I think it's important to call this out because it would give project open source project and maintainers insight into what motivates new contributors, especially non-good contributors, to not just come come to your project, but to remain and grow within within the community. So, yeah. These are my mentors and me. We We made up the research team. So,
you see, like I said, there's a woman, there's Amy Suba. there's Andre and Arthur. They are all uh they all work at Waffle and Labs. So, when I looked at the mentors, I saw there was a woman, okay, yay. That's represented. I saw Um Andre is a UX researcher, too. Amy is a product designer, and Arthur was a mentee for Promethius at some point, like a few
years back, and he has consistently consistently um like he has grown to become a maintainer in the Promethius project and has consistently mentored people through the LFX mentorship program. So, and then there's me. >> [laughter] >> Then, the challenge. Definitely, there'll be challenges because this is something that we're doing for the first time, both for the community and and for One, there was no precedent for UX
research in the in the project. So, we had to think beyond just completing the research itself. We also we're trying to establish a foundation. >> [clears throat] >> Establish a process that future UX folk and coming and the community could build on later on. And um yeah, I mentioned that I was Prometheus and Open Telemetry. So, these are two big open source projects that are really mature
and are somehow set in their ways. So, it was they they have different They have different cultures, different priorities, and workflows. So, we had to be careful, thoughtful about how we approached conversations and feedback across these two communities. And then engaging maintainers who and other stakeholders and by stakeholders I mean um the project uh co-founders as well have you know how open source open source contributions are?
These people have your jobs, they have other things that they're doing, and you are this is a mentorship that we're doing. I mean, we don't want to interfere with their busy schedule. So, also the results of this UX research was most likely or potentially um affect whatever these people are building. And so, it was important for us to involve them early on in the process. We didn't
want to conduct research in isolation and then show up with findings later on and expect them to to just accept it. That's not the way it works. So, part of the challenge was figuring out how we would involve maintainers and contributors in a way that respected their time while also get getting meaningful feedback. Doing you doing the third challenge the first challenge, sorry, is doing your UX
research in a domain I barely understood and I think this this this clearly is very obvious. get context about the problem space that you're in because if otherwise you would easily misunderstand a problem or you could draw wrong conclusions or misrepresent findings. And on a personal level like it's easy to feel like an imposter when you are surrounded by people who seem to know more about the
project than you do. So, these are the challenges we faced. So, we had to come up with a plan. Um and that plan involved one that was scour scour the web for existing UX research resources in other open source communities because clearly even though Prometheus wasn't doing UX research for the first time, there are other product communities who have done um who have integrated UX research into
their workflow. Um and a resource that we found was GitLab's resource that we found that was really helpful was GitLab's um UX research handbook. Then we also plan to integrate into and engage with both Prometheus and other communities as early and as often as possible. And then also learn enough about Prometheus and open telemetry to have basic context of the inter- interoperability problem space. Now the process.
So, I'll Okay, maybe I'll say that later. So, the first stage of the the mentorship is one, like I said, I wanted to integrate into the community and engage with them as early and as possible. So, I had to introduce myself to and and the project that I was working on, the UX research I was going to do to the community both the Prometheus and the OpenTelemetry
communities. And then we planned weekly sync with my mentors to keep them up to speed. And then we created a schedule. It's important that I call this out um it's not a fun creating a schedule, well, it's really important because it helps you know what you are going to be doing during during a particular week and lets you know so that if if there is no time
for a project that has a time that is time-bound, because this mentorship was supposed to be for 3 months, if you have no schedule it it you kind of go off track. So, creating a schedule was was important. we had to plan the research approach and the method where we are going to we are going to run surveys or interview users and if we're going to do
that, why are we going to like what about the research goals prompt us to use a particular research method. Then I went on to research about Prometheus and OpenTelemetry as and as projects and how other open source communities do research and UX work like I already mentioned in the previous slide. in stage three this is the actual research work, the actual UX research where we ran a
survey um I conducted user interviews and then interacted throughout this process we interacted with both communities to help with outreach and yeah, shout out to the OpenTelemetry and User Seek because they really helped push the push the surveys and help and help us get more participants. the final stage is to analyze the responses from the survey and the and then I went on to document and share
that with the community via blog post. Um, the project is on the open telemetry blog. And then there's a GitHub repo where I documented the entire research work. Um, I have a link to it in the last And then also in community meetings and at events. I like I'm happy to share to say that I had the opportunity to share these new results or the reports of
this UX research at PromCon and KubeCon North America last year. And that's a very big feat for me I must say. I'd like to point out too that on the screen like this slide looks it looks the process looks very clear but it wasn't so clear when we started out. We had to figure things out as we progressed. So like in hindsight it looks straightforward but at
the time it wasn't so so laid out. And yeah, that was the end of the research. Uh, not not exactly. if you're a UX researcher you are already familiar um, with the flow that a UX a UX research usually has two possible outcomes. One is either the research remains unused. In that case the research results just sit on the shelves and nothing is done And another outcome
could be that it gets used. In that case the UX research results results it drives project directions and decisions and leads to impacts or changes. And I speak for all UX researchers when I say that we want to we want our UX research to be used. That's the essence of investing all that time into it after all. So, and I'm happy to say that that is exactly
how um UX mentorship or UX research that we um that's just exactly how it went. From our UX research, we we found out a couple of things, but for the purpose of this talk, I'm just going to highlight two. One is that um Prometheus had to expand that it could expand to more exploratory telemetry use case. What this means is that the way Prometheus currently operates, it
it assumes that the user knows what they're looking for. So, it's like um you go to a doctor and he um you've already told him what your symptoms are, and he just runs tests to conf- to confirm what he he he has suspicions about. I think it's called a differential. I'm not a doctor. I don't know these things. So, he does tests to confirm that, okay, what
he what he thinks is the problem is actually the problem. So, that's how that's kind of how Prometheus operates. It assumes the the user already knows what he's what he or she's looking for. But OpenTelemetry collects not just a particular type of signal, but all the signals that you would need from your app. They send it to Prometheus or any back end. one of the key findings
is for kind of operate the way OpenTelemetry does on that assumption that the user does not doesn't know what they're searching for, but they want all the information so that they can correlate all of them. And that is what this exploratory telemetry use case is all about. And the second finding is that there are documentation gaps. So, they there were no clear documentation around OpenTelemetry resource attributes
and how Prometheus handles OpenTelemetry So, uh I'm glad to share that a mentorship like this led to this finding has two new mentorships within the LF mentorship program. One is to prototype meters for exploratory exploratory use cases. Um this was worked on by Anna Muenz, who you'll see her later on. And then there's this one that is currently ongoing for which I am I'm one of the
mentors. Yay. It's a um documentation mentorship to improve docs for Prometheus and OpenTelemetry. So, yeah, we see that like we've seen what this UX research that Prometheus did has led to. And like it's it's really nice to to see. So, our UX research uh research team of four has now become a UX working group. So, Prometheus um like Prometheus now has a UX working group as a
result of the UX research that we did. And now we have one remember Anna Muenz who worked on the prototyping mentorship program. So, and one thing I like I like one side effects or ripple effects from from this mentorship is that um now now we're growing. There are three women in the team and two and two men, four of whom are non-technical. All of us are UX
designers besides Arthur who is a software engineer. So, yeah, there's more now there's more representation, there's more diversity, and like these are things that are important to see within a locus first community, especially one as big and as mature as Prometheus. So, yeah, the lessons. I'm sure this is the part we've all been waiting for. So, what did we learn? What did we, that's me, I the
mentee, the mentors, and the project itself learn from this experience? First, mentorship can be a safe way experiment. So, because this um exercise was framed as a mentorship, gave the It gave the Print community a low-risk way to explore UX research. So, it didn't require adopting design practices yet, but let them see if there's space for something. You let them see what this could look like for
their community. Lesson number two is >> community engagement matters as much as So, much of the work that we did wasn't just conducting interviews or analyzing findings. Um it involved talking to maintainers um and explaining the goals of the research and making sure that people understood how it related to their work. And in in open source communities, um research only works when people feel included in the
process. Lesson number three is that design impact is not equal to design outputs. What do I mean by this? sometimes, like I already mentioned, you may not your your research may may just sit on the shelf. You may not lead to changes within the project. You may not They may not be extra work done based on research that you've done. But that doesn't mean that you your
work was useless. So, even even when the research doesn't immediately change product decisions, it can still have value. And in the case of this mentorship, yeah, it's true it led to It led to two new mentorships, um but also helped introduce research practices into the community. Um it created a foundation future UX and design work. So, sometimes the the early the impact of design work in open
source is that it opens the way for more work later on. It may not be immediate. So, it's something we should um take away. Lesson number four is community trust precedes design influence. before your research findings can influence design decisions within the community, the community needs to trust the process and the people doing the work. And how do they build that trust? By you have to be
transparent with them. That trust comes from comes from transparency, constant communication, involve them every step of the way. And now the key takeaways. So, I'm going to like this part is addresses addresses the two key categories of people that I expect to be at this talk and that is project maintainers and um UX contributors who'd like to contribute to projects. So, for open source maintainers, um I'd
like you to take these key points >> [snorts] >> Create space experimentation. It helps It helps the project um you get more diversity, not just in terms of the demographic, but in terms of the kind of contributions to your project. Involve the community early. This This also goes for UX design contributors who are coming into projects. Visible presentation matters. That I can't emphasize this. Treat UX design
and research as collaborative and not external. So, don't look at it as something outside of your project because it is an internal as as a collaboration, basically. As an investment, not a disruption. Don't think they're coming to change the way you already work. Instead, um it's an investment. It's At the end of the day, you are you are your project serves users. UX designers and UX researchers
are coming to help you design better product products for those users. So, you are on the same team. And for UX designers who are coming to contribute to open source projects, when you come in, please observe how the community works. Don't be >> There's this um Igbo adage. I'm I'm from Nigeria, by the way. An Igbo is a tribe Nigeria. We have this adage that when a
chicken moves comes into a new environment, it stands on one leg. It doesn't immediately stand on on two legs. So, with time it it balances itself on both legs. So, what that means if as a UX contributor, you're coming to a contribute a community, don't be quick to propose changes. It's It's nice to observe how the community already works, and then you can see areas where you
can make meaningful contributions, and try to start small, Don't come Don't try to come and overhaul the entire process. Um yeah, involve the community early. Whatever it is you're doing, communicate, communicate, communicate. Be patient. Impact takes time. The mentorship was for 3 months, but um I continued contributing to the community till date. So, um when you go to the community, come come with an open mind that
this is where you want to be, and make your contributions from like wholeheartedly. Document and share findings openly. This This is important, because I like I think one thing that helped that helped make this um research gets to get the outcome that it did, leading to two two more mentorships and having the Bromage community adopt some of the research findings, is that it was shared widely in
the community. People A A of people talked about it. It was It was talked about at From Con. It was talked talked about at Keep Con. So, yeah. Share your share your um findings publicly. Let people talk about it. That is how you get to That is how you get people to act on your research And yeah. Now, I've come to the end. Like the actual end
>> for instance of the of my Prometheus story. And we all lived happily ever after. So, like my hope is that more open source communities will experiment with design mentorships like Prometheus did. And that more designers will feel encouraged to contribute to open source projects as well. And yeah. These are the resources. Oh, like uh now I realize that I should have used a QR code which
is easy to access. But hopefully it should be on the on the website. On the First Batch website. So, yeah. I think I can take questions now. Thank you very much for listening to my TED Talk. Thank you, Victoria. Do we have questions for for Victoria? Um oh, is it Oh, okay. Um I'm always curious to hear from other designers in the open source space. What was
your most like challenging conversation that you had with uh the open source community and how did you navigate the challenges of um communicating design and how it's valuable in in the project? Okay. Um thank you. Um I'm aware of that question. So, one one of the challenges that I had first of was in in design room. And I had to interview stakeholders. I had to interview the
project co-founders. These are people who have tons of information tons of knowledge about the I kept I kept postponing doing those interviews. >> I remember telling my mentors that, "Oh, how do I reach out to these people?" And they said, they're like, "We we could help we could reach out to them for you, and then you can just join the call and ask your questions." So, on
one another challenge besides that imposter syndrome of having to reach out was that some of some of the projects maintainers or co-founders are opinionated very opinionated about how they want the projects to be. And I don't blame them because this is practically their baby, and OpenTelemetry and Prometheus have this very weird dynamic. OpenTelemetry has this huge community behind it. Have they are set in their ways of
working, Prometheus is doing the same thing. So, one one of the questions that I asked during the stakeholder interviews was so, what like how much change the maintainers were willing to accept the result of this GSoC mentorship. So, um like what are the non-negotiables? What are things that have to remain the way they were, and what are some areas where, "Okay, we we can compromise in these
areas." So, when I found those out, in the in the recommendations, I made sure to mention those, too. So, that whoever is going to be working on the outputs of that GSoC project would know, "Don't don't touch this area." >> So, yeah, I think I I might answer the Thank you. Thank you, Victoria. Do we have other questions? Uh hello. Thank you for the talk. Uh, I
wonder what type of uh methods did you use for the research? I heard the interview, but I wonder if you engage in forums and things like that, or what other channels did you engage on? And uh, what sort of advice could you give to, you know, uh, I talk for myself. I fail miserably on uh forums, and I get no responses. So, I wonder if you have
any insights on that area and the channels. >> Yeah. So, um we used our research method involved a mix of I don't know if you can hear me. My video is frozen. It involved a mix of qualitative and quantitative research. So, um qualitative, we did we did user But, and then quantitative, we we ran surveys. From the surveys in this in the survey questions, we asked if
there are any of the survey respondents who'd also like be interviewed. So, it was from there that we got our pool of interview for outreach, at first, we we posted it on the like we had this banner on the Prometheus website, so that people could people who were coming on the website could easily um could see that we were running a survey and fill the form. But,
we noticed that the bulk the majority of the people signing up or responding to the survey were Prometheus people already using Prometheus, heavily Prometheus users. We wanted people who use both Prometheus and OpenTelemetry. So, we collaborated with this end user SIG, because they also run surveys in helped publish the slide the survey on the open animation websites. That was how we got the our target like a
sizable number of survey participants and um interview participants as well. the like I'd say at some point we have to leverage our own personal network. I posted on LinkedIn and other social media platforms. So, I'll say and on Reddit too. Reddit is another good place where you So, I'll say it depends on the community what the challenge is about. find out where your target users are or
target audience are more likely to hang out and share it there those online forums where they may be. Also, at a talk like this you could reach out to speakers at big conferences and say, "Hey, I'm running a survey that's related to these things. Could you add this QR code so people could know to fill this survey?" So, there's that. Thank you. Do we have more questions?
We have time for one more question. It appears that there are no other questions. So, we thank you for the >> [music]
More from this event
See all 47 talks →
Seyi Kuforiji – Bridging the Gap: Encouraging African Talent to Open Source #FOSSBack
23:57
Educating the next generation of open source contributors #FOSSBack
36:35
Jan Dittrich – Best practices and (very) small projects #FOSSBack
24:03
Johannes Näder – Let’s tackle Openwashing! #FOSSBack
24:58