So thank you, the next one is Otto, and he wants to understand the number of needs, which
is understandable after talking about the number of needs on the five today.
And he's going to talk a little bit about his research in 4th of June, if you're waiting
to say.
Yeah, thank you very much.
Actually, we, for Joe Contributors, had a nice meeting yesterday, and we might have found
a perfect way to integrate, design, and use a research into our issue tracker, and
organize it in a perfect way, maybe we'll see.
In any case, I will talk about the challenges we are facing, the things we tried, some lessons
we learned from that, and how we arrived at the idea that I will present in the end.
Yeah, actually, I do have very technically background, mostly in web development, and I would
not consider myself as a designer yet, but I'm definitely becoming the user researcher,
and that's primarily because I think that technology sometimes sucks.
You agree?
You hear quite some people laughing, I think some of you agree.
In most years, I never really cared about user experience to be honest, because I mean,
user experience, I mean, it's nice to have, but right after I'll fixing all the bugs,
I will get to that later, I will also implement all the features first, and maybe fix
all the accessibility issues that my software still hasn't.
We can talk about user experience later, but the technical frustration I had with the
like a very specific tool made me look into user research finally.
Yeah, I'm also involved in a code brick for several years now, a code brick is providing hosted
infrastructure for software development, like we decided that Microsoft GitHub is not the
right tool to host a pre-librator software project, and it's actually very set how many
free software projects still depend on large monopolies from the large companies of the Earth,
some would even say the most evil company of the Earth, and yeah, we offer Git hosting,
issue tracking, CICD, static pages, it's replaced translation platform, and much more.
We're open to free and library software projects, and we're powered by donations and membership
fees of our legal nonprofit association, we have about 1,500 members, most of them even have voting
rights, so we're really basically the opposite of GitHub, but still working on open source software,
and also only powered by open source software, which brings me to Fujayou.
Fujayou is one of our project, of course, it's also a real resource community, but it's something
that you can host yourself and something that could brick hosts. The history of this software
project is longer than could bricks, but we fork this software over disagreement with the previous
upstream. The nice thing about Fujayou is that it's a really nice community, and actually it's
a fork is actually challenged, because you proliferate workflow, and you say, okay, can't
we all agree on the same thing, can't we collaborate on what we do, but a focus also chance to
question the established workflows, and the nice thing in Fujayou is that we did, and we changed a
lot of things. We completely stopped depending on proprietary services, like group placed proprietary
CI with a pre and library one, we moved the translations from a proprietary platform to library one,
this is actually a nice idea, and the next thing that Fujayou does really nice, they
pretty early agreed on doing user research. Actually, before I got involved, someone started doing that,
and it was stuck for several years, but it was communicating that the Fujayou contributors
are open toward this, which is actually very important to me, because since I've become a member
of design and just speaking in a non-technical role, I actually see that a lot of developers don't
take me seriously, and I'm very happy that at least the Fujayou portrait team does different.
Yeah, actually, I wanted to get started, and I started reading about design. I mean,
I use the research, and for me, coming from a design background, a lot of terms have been
strange. I mean, probably designers don't know what would old technical terms mean, and I was
confused about user research, user experiences or testing all these terms, and actually it's very
sad, because they are not very much resources on the topic. I'm used to having tons of block articles
that talk about how to do X in this technology, that technology, blah, blah, blah, blah, they they
there's really a lot of resources about how to do technical things, but for free-level software
for open source design, I went to the open source design website, there's the resource page,
but a lot of things are just down, not found anymore, behind paywalls, and actually, I can
recommend the e-beginner's guide to finding user needs from Yanditrich. It will actually help me a lot,
yeah, it is free and liberal. And yeah, also a lot of articles kind of start with, like,
this is how you convince your management to do user experience and user research,
and this is how you increase your conversion rate, and just feels weird as a pre-software
contributor to see a lot of marketing pre-phase, then I just want to know how I actually do it.
Yeah, even after reading the book, I was still slightly confusing how I actually get started
and what the first step should look like, and there was one very, I went, I was very tired
in one specific Sunday evening, I was like, okay, maybe I'll just create the next cloud calendar
appointment, I will just post it on MasterDone and we'll see. So I did, when just sleep,
the next morning I woke up and I had a fully booked week, actually. I had about 18 sessions in one week,
most of them booked overnight. It was definitely a great experience, I can recommend this to you.
I was not prepared very well, I just just started it and improvised, and it went very well.
I think the, especially the first sessions, they've been very valuable, because I learned a lot of
things from users. If you're going to do that, I suggest that you just focus on like five sessions
for a start and evolve over time, because I feel like the first sessions have been really valuable,
and then it started to kinder become less valuable, but it's still very nice.
Yeah, and at this point, I want to clarify that when I'm talking about user research,
I'm talking about understanding users, and often I don't really know how to turn the things
I learned into actual user experience improvement, but this is a separate thing, and even the things I learned
about our users have turned out to be very valuable in certain decisions when thinking about like
how to place a button. I can't know for sure, but I have a lot of data to back my
and to make an opinion, an educated opinion, basically.
Yeah, I also have been very surprised during the sessions, because I mean, I had a mental model
of a user, like implicitly, and never really considered it, but in my head, all the projects
use this kind of look like me, male, maybe young, somewhat skilled with the technology,
and yeah, of course this was partially confirmed here, and we use a research, but I was also
told different, because there are a lot of things that are different, and especially some
users really have no clue how to use our software, because they used to other platforms.
I never considered that, because I knew that people are coming from GitHub, but some people
haven't even changed to GitHub yet, they are used to completely different workflows,
only over locally, or they are ledger to make contributors without any tech background that are
just, just edit the file here, you will figure out your way, but actually file editing in
for jail is super complex, if you use a rep UI, because it was created with this developer's
in mind, and not people who have never used Git. Yeah, and I started evolving the user's things
that I did, I did user testing, I did user testing, which basically means I led users,
user software and observed with the challenges they see, but I also did user research using
other platforms, I think it's really valuable to see users using other projects, not only
years, so I've seen people using all the source for just on Earth probably, I have done a lot
of interviews just asking about what actually trying to do, how do you organize your project,
what would work well for you, and just learning about what they're trying to build. I gave them
tasks like just do this, and I observe how it does, like my personal favorite is create an
organization and then the user treat. People fail miserably because it's really complicated,
but I've learned how where users expect to, how to add a user to the organization, because
they click somewhere, it doesn't work, but at least I know this is where users click, if they
want to solve this task, and maybe I should make it just work the way they expect it.
Actually, I even gave users tasks that are impossible or not implemented yet, of course,
I resolved this quickly, but just to see where would users expect this new functionality to
how to work like, and this was also very valuable insights at some point.
The last thing that I did sometimes was, especially for setting, that are really complicated,
it was like, okay, imagine you could create the settings, and you just overtake objects that
you have a mind is there, how would it look like, and then they told me how they would configure
a project, and of course, it does not work this way, but at least I now have a mental model of
how our users expect there, I don't know, repository settings to work. This is also really
valuable in my opinion. The thing that I did next is actually evolving this by different things
and communicating this, and I usually did raw transcripts of my sessions, I highlighted conclusions,
I tried to scale up the team with more designers, but this also brought some challenges.
For example, the challenge of them, not completely being aligned to our free library software
ideals, they were just often like, can I use Google Calendar, and of course, this is not what we
want to do, but yeah, and the next challenge that also prevented designers from getting into user
research and project is that we have a lot of complexity. I mean, all the design guides that you
have, they basically show like, this is how you reuse a research on a web app, and everyone can relate
to it, that you get a task, and I understand what the user is doing, but if I asked the user to just
do something, they are not doing it with a theoretically simple way, but they are doing it in
their very complicated way, and they tell me about very complex needs about their complexity,
ICD pipelines, and how they integrate home automation with the iPad lines, and very complex
stuff, and sometimes like one challenge for me, if I do a screen share, and observe the user doing
something, they are just too quick, they just switch between apps, they are typing files, and I do
they use tools that I've never seen before that abstract, the thing that I'm used to know,
even with my technical background, I really fail to understand what users are doing there sometimes,
and I try to invite some of the project developers into doing user research, but they're not
going to do it, we have to be honest. Yeah, so the things we do is really, I really
are trying to understand without having domain-specific knowledge, and I really need to integrate
our developers into the tool chain, but they're not going to spend a lot of user research sessions.
So, the second challenge that we have is the issues that we have, and they are of a
writing quality, of course, some people write very robust text, have very complicated ideas,
some write very brief, and over time I realized that, at least in my opinion, the workflow that
most free library software projects have are actually not working very great, and I will ask
you question to the audience, if you raise your hand please, please keep it raised even for
the second question. Like, have you ever been, have you ever created an issue, or like you
probably already created an issue in some project? Have you ever been confused about whether to
file it as a back or a feature, please raise your hand and keep it raised, did you choose
something that did it wrong, please raise your hand in addition to it, like keep your hand
raised and close it, okay, and if you're maintaining a project, have you been ever annoyed
because someone did it wrong, and filed it the wrong way, he also some people are annoying,
he actually backs feature requests, does this, this is actually a good idea, and I started
to question this, and I realized that actually these things are rather modeled around finding
a solution. Like, if we, if we ask for a feature request, we ask the user to think about what
they want, without describing the problem, and sometimes we have things that are really not
clear. I mean, people write, I need this button, and if you ask why do you need it,
yeah, because it does not exist yet, but the actual, the actual thing behind this is like,
what do you want to do with this button, and in the software we have, I mean, it's really old,
it was inherited over a several projects, we have a lot of features, and all who we know,
like the discussion that led to the implementation of something, we don't really know why
it was actually needed and which purpose it served, there was like a discussion to implement this,
it was accepted, it was implemented, but we have no clue why, and which purpose it served,
and people abuse it in very different ways. Yeah, and I will show you something here,
this is how I perceive this to work. I mean, people suggest a solution, and my favorite is about
single sign on thing, so people suggest to put custom text on the sign in page, because then they
can tell users to how to sign in, or you have to disable local lock-in. Without, we don't know why,
but people asked us to disable local lock-in, or they wanted to disable the lock-in sources,
certain of them, or they wanted to set the default lock-in source, or they wanted to redirect
to a specific lock-in page, but the actual problem, all these features requests, all these
just one problem, because if you have a company and you have a sign in with, and you still have
a local lock-in, people will fill the local lock-in with their credentials, or they should
click on sign in with my university, or sign in with my company, and all these problems,
basically solve the same problem, and some of them solve it even in a bad way. For example,
disabling local lock-in would prevent you from having a local admin account or a guest sign,
and so if we implement this way, we also need a different solution to the same problem,
the same with auto redirecting, and some solutions actually address different problems.
For example, here, the actual goal of disabling local lock-in was that users
that are still able to configure a different lock-in source, or set a password, even if they
are not supposed to do that. So they try to solve, like, actually, a different problem this way,
if you don't know the solutions are supposed to solve, I mean, the future requests only look at
this, and we have no clue what they're actually supposed to do, and I think this is a big problem.
Yeah, the, oops, sorry, I just, and the next problem I was pacing personally was that
developers have motivation. I mean, if we have paid stuff, we can just tell them to work on the most
important issues, but actually our developers have personal motivation, and they're naturally
opaque, the tasks that are interested in. And so even off a label, a lot of issues, and they're like,
this is really important, no one picked them up, because no one was motivated to work on these tasks.
On the other hand, developers have been really motivated to work on something, but I was not doing
research on them, because I mean, it's probably still important, but I can't do all the things at the
same time, and I had no clue what developers are actually interested in working on.
Yeah, so there was a mismatch between what I was doing and what the developers were doing,
and so my idea was to integrate the research into the issue tracker. I tried to split the
problem description from thinking about the solution by using like two different templates and
suggesting where people should start, and yeah, and try to involve all the developers into
trying the different issues. And the problem of this work was basically that a lot of
users were confused about where to start. They used the wrong templates, they were really angry
at us, because they were like, I've never seen such a complicated process in an open source project,
I just want to file my future request, please. Yeah, and some contributors also did not really
understand the workflow, which is of course not bad if you want to have like all people like
Rean workflow. And actually it was lost for like several weeks now, or like actually
months, about thinking how to solve these problems and iterating on this, tried to change
wording in the templates, explain them slightly better, but yesterday we had a meeting with
some for jail contributors, and we actually had a very nice idea, and it's really lucky that we
talked about this beforehand, because now I had was able to accept my talk, and what we are now
trying to do is we clearly define stages, because I mean different types of issues are somewhat
hard to communicate, but like a process that follows certain stages is much easier to follow.
We try to create shortcuts so that people don't feel like they always need to go through
complicated workflow, but they could fast-track certain things. And what we do right now is basically
splitting issues into what is actionable for developers, and what is like still in the process of
being worked on, and a lot of projects implicitly do this by having like a separate forum from
their actionable issue tracker, but I feel like an issue tracker allows has the power to cluster
things with labels. Like this is only an example, I have much more research labels where just cluster
issues, and say yes, I want to look into how, for instance, this configured, I have a lot of users
that are confused about how they can filter for issues, pull requests, whatever, so I have
a cluster everything that is related to this, and so on, it really helps me
specify the various described problems. I have illustrated the workflow that we are currently
trying to go for, so users actually start here, and they file an issue by describing a problem,
and only describing the problem, ideally, and the issue is in the triaging stage, and every
project contributors is supposed to take a look at this, and decide, like is it a really simple
problem, like is it something that we are completely sure about how to work, and we just did a mistake,
and it is broken, so we can directly label the issue implementation, and some developer knows,
okay, I will fix this right away, because it just clear how it's supposed to work, it just needs to
be done. If not, then we usually enter research, or we want to enter research, I mean the research,
that is from yesterday, we of course did not try the ad, but we want to try,
understanding the actual need of the user, and collecting more data, and also finding like
other problems that users described that could be related to this, and once we have gathered data,
we want to enter the design stage to draw conclusions, and only when we are satisfied, and I mean
design does not only mean technically design, but also UX design. Once it's described, we enter
implementation, and the issue is ready for development. I hope this will work out. Actually,
the other two arrows mean that we sometimes could create issues, because as I described before,
like something could use this could describe several problems, and we want to have one issue
that tracks the various problems into one issue, so we would start from scratch there.
Yeah, and I'm really looking forward to trying this out, and I'm curious about what you think,
and if you have any questions, just leave me no, let me know.
I'm saying a lot of big questions. I'm sure you repeat the question, I think.
You've been in this work, but it seems to me that this might react to it, so it basically depends on
some of our first reports, and I think that's a kind of separate problem. We would, of course,
prevent what you describe that we have a reactive workflow, but I think that, like, as a user
researcher, I see that users describe a lot of problems in the issue tracker, and the problem that
I'm trying to solve is specific to making use of this data, because it's currently not really used
in my research, and that's a specific problem I'm trying to solve, and what I, of course,
hope is that this makes our software better and avoids UX problems in the first place,
but in my opinion, just not replaced having a UX designer who gives valuable input about
how to design features in the first place. I think what you address would fit into the design stage,
and would be very great to have more input into the design stage to be currently,
don't have a true designer, still looking for one. Oh yeah, sure, go ahead.
I would like to know, as you mentioned, that developers like to work on what they like to work on,
and then you have this take-a-existence, that is the solution to that problem for you?
I'm not quite sure if I understand this question.
Present that the solution that you came to, is that addressing the problem that developers are picking
up, okay? Yeah, the question was about whether this addresses a motivation problem, and I think
it does, because this allows everyone to proceed. So like, if a designer, I like, if a developer wants
to work on something that is just reported or they even reported themselves, they can now participate
and moving this forward without requiring the user research team to help with that. And I mean,
of course, it would help if we synchronize our team members, and I know what others are motivated
to work on, but currently, the words for that we previously had basically depended on me knowing
what someone wants to work on, and then doing the work. And now I hope that this allows the
project developers to also do the workflow, and it does not depend on me knowing what they want to do.
And yeah, I think it does address at least part of the problem. Yeah.
Hi. You basically have a focus on labels for the user's engineering, and that's paid for the
questions following. In this workflow that you propose, do you think that using labels will be
fine for starters for going to work for like this, or do you expect that you're probably
going to have to make a policy case with Brazil itself, so support this portfolio.
Yeah, the question was whether it's workflow works well with Foggio, or if you have to add
something. And I mean, of course, I designed the workflow basically around what we have,
and I'm pretty sure that we will see challenges. For example, the filtering options that
we currently have in Foggio don't make it quite easy to support this workflow, because you
because you can't, for example, have sub-labeled, and so on. That's what would be very useful to me.
But I have used the labels actually not specific to this workflow. I've used them in the past,
and I think it's possible ready to work with the labels and cluster issues this way.
Okay, yeah. I think this is mostly too for their contributors to the type. This is, okay,
yeah, whether like who decides how we go from triaging to implementation, and this is actually
the decision every day for their contributor could make, but I mean, at the moment,
like the matter is, like if someone is looking at this, and they have the technical knowledge to
to know that this is just the way this intended, they would just set the label the same as
currently people are moving the feature request to box and vice versa. Of course, there's a chance
that someone clarifies the box as, okay, it can be implemented, and actually the feature that
is broken would need to redesign anyway, but I think the chance of this happening is low enough.
And I mean, given that we can sometimes just have like a few comments discussing this,
and it's just a consensus of like three contributors to move it forward,
then we don't have to, you know, enter all these stages. Thank you very much for your attention.