Who are the "users'?

[Erioldoesdesign]

Sometimes there was a fuzzy line between the "users" giving feedback and the "people that also contribute" to the project. This is in contrast to other research on the role of users which is often attributed to those "outside" of the organization (Woolgar, Steve 1990; Agre, Philip E. 1995.). The definition of when an OSS stakeholder is a user, community member or a contributor is unclear. If the stakeholder also helps to develop and build the OSS in a "has committed code" way then they are typically called contributors and if not, they are named as users or community members. These different ways of categorizing "users/community members" and "contributor users" expressed itself in what they were involved with and whether this was "active" (participating in discussion in a meeting/issue, writing responses to accessibility needs etc) or "passive" (being a "tester" in a usability test scenario). A way of addressing this confusion about user definitions could be through collaboration with design researchers, who help projects understand the nuances of their users. Knowing that designers can contribute this user definition work as a design contribution is a good step towards better understanding users and where their insight is most valuable (in regards to their OSS usage) and also in inviting design contributions beyond ‘visuals’.

As one designer states “I did not speak with users that aren’t part of the organizer team”. This phrasing suggests that the organizing team are also users but not the kinds of users they had in mind for the particular task or need. Here we can see a clear way to improve user centered design in OSS by helping designers to define rough definitions of user types of the OSS collaboratively with OSS project team members.

When discussions were held about any aspect of their work or the design of the OSS, designers largely described maintainers, developers and other people involved in the OSS project as "contributing" and "collaborating" on design. This supports the idea that some OSS is built in community with others and that everyone involved in using, contributing or collaborating with the OSS is part of its sustained existence.

The most contact users had with the OSS was typically through structured usability testing in meetings. A designer had tried to create an asynchronous process for gathering usability insight but it was unclear if they were successful. “We discussed trying async usability testing. We have not actually tried it yet but discussed the pros and cons and started forming a plan.” As with many user focussed design processes, it seems as if the limiting factor was the approval process for the "formalization" of gathering usability insight. As researchers we see this gap for open resources for designers contribution to OSS and the OSS projects themselves around asynchronous usability testing processes, formalization of usability insight and helping to understand when user feedback is at a state that is permissible or substantial evidence to progress a user centred design decision.

One unique usability testing interaction was not designer initiated. A graduate student researcher who tested (the OSS) in their work reached out to the designer of that OSS. This graduate student researcher and the designer decided to meet up at a conference to discuss these results.

Another way that designers learned to understand users was through a website’s usage metrics. They were able to tell when "users" started accessing and using a particular website page they had designed and built. “I suppose much later when we get real user feedback on the built form we will know if the suggestions incorporated into the design this week were useful or not. But we won't receive that feedback until more development work has been done.”

The term "real" here is interesting and relates to the beginning of this section where our designers had trouble defining who was considered a project collaborator, user or fellow contributor (user). In our researchers' experiences, developers and maintainers can be viewed as being ‘too close’ to the inner workings of an OSS tool to be described by designers as effective user feedback sources. This further expands the complex issue about how to describe different types of users in OSS.

Broadly speaking, users were defined by their participation in usability or user testing. Testing was used as a positive mechanism for many of the designers to involve developers, other designers and community members of the OSS into "user insight" design processes. This appeared to lead to, in later weeks situations such as “The team (developer and leads) had discussions about user-friendly labels for describing data types, had discussion about the UI for a filter” and “The project lead for the browser extension started an outline for a human-readable information architecture for our data”.

The other notable definition of a "user" is when "bugs" were submitted in relation to design. “One user mentioned that the registration button on the mobile sign-up landing page in the event was missing”.

Finally, there was one instance where a designer directly collaborated with a user on design work “In the (OSS project), I designed in contact (collaboration) with the team that is the user too”. This could be one case of participatory design in OSS, or as close an extrapolation from the diary study data as possible.