Wikimedia Developer Summit/2017/Creating a UX-UI open hub space for Wikimedia

SESSION OVERVIEW
Title: Creating a UX/UI open hub space for Wikimedia?

Day & Time:Tuesday 10, 1:10 pm – 2:10 pm

Room:Prince

Phabricator Task Link: https://phabricator.wikimedia.org/T154545

Facilitator(s): -

Note-Taker(s): Seddon, Quiddity, Elitre

Remote Moderator: Melody Kramer (?)

Advocate: -

SESSION SUMMARY
Purpose: Creating a UX/UI open hub space for Wikimedia?

Agenda:  Let's discuss/brainstorm about the following topics:
 * 1) Does open design fit our context?
 * 2) Open design vs Open ideation
 * 3) Problems as stories
 * 4) The Mozilla identity use case
 * 5) Our software vs our communities

Style: Problem-solving: surveying many possible solutions

Action items:
 * 1) Should the conversation be including non-WMF wikis?
 * 2) How do we have positive conversations internally?
 * 3) How do we incorporate larger audiences? - Most important question
 * 4) Let's start by piloting with a small project (?)

Does open design fit our context?
We are not necessarily going to the community for answers but we have designers.

What problems do we want to solve. What we identify.

Open design vs Open ideation
Open ideation is stacking the ideas that we need to address. E.g. problems with browsing articles on your phone, and we create a list on wiki, and then tackle the individual issues [...] Open design is [?]

We don't really have either right now. It's been getting better over time, but much improvement needed.

What's the best formula for open ideation to allow the community to voice their concerns and allow designers to listen and it be a two way process. 1 wish I have is around scoping ideation. Either the full community.. can we scope what we're going to ideate on? Can't have fruitful conversation about dislike of colors. Open IDEO process ( https://openideo.com/ ), they use people throughout the world, to answer complicated problems like: death with dignity, and healthcare, and [?]

Your level of comfort as a designer is high when you are comfortable having someone come into your area. Designers are more than happy to take into account limiting factors but there is a difference between the difference between designers and ux engineers.

The only resource we have is the design research team

We haven't had an open ideation process but we do get feedback from users who are using the tools and that gets incorporated.

In the iOS there are places to give feedback but it's not heavily encouraged.

Are there examples where open design works?

Not sure, this is going to be new for us, we're quite peculiar so nobody else probably has been in the same situation.

We have previously been in a situation whereby we have tried to push new design ideas but without proper/clear justification and resulted in community push back (related to mobile).

Whilst we haven't done some of this before, perhaps we just need to focus on the base layer, and small fixes to the existing UI/UX, and then build from there. Instead of trying to overhaul or drastically redesign things.

Similar concerns about new tools, and other types of change. Change-aversion in many languages/projects [...]

Don't be afraid of trying to bring about change.

This aversion to change occurs across all types of software developement environments. We should take the factual criticism out of the feedback, and not treat it as purely negative, despite the occasional bad phrasing. [?]

The design of the main page on spanish wikipedia involved the community and it can work.

We are doing a better job of involving the community. But the feedback sought and type of engagement should not be post -fact. It should be part of the process.

Are some problems Design issues or Product issues? Design is on the top of things, but whether something should happen/be made or not it's ultimately a Product problem.

Problems as stories
We need to be very clear about the type of process. People might bring entire new mocks ups but there is a question about bringing in user stories as being part of that process.

The Mozilla identity use case
Mozilla discovered that their logos don't represent what they are. Mozilla went through an open design process. Since summer 2016 and are in voting.

Our software vs our communities
Integrating the voice of readers in our processes, as we currently don't get much of that.

The community doesn't necessarily understand interface design.

Defining the design goals (roles?) as part of the open process can help lead to better collaboration with less argument. Coordination is necessary, as things such as templates (infoboxes, article banners) etc. are part of the UI, but the community doesn't necessarily see that.

Idea: Could have a hub where people create a high-level topic about a problem, and then link to and/from an example page, then discuss the problem and file the results in phabricator. [?] Feedback from apps is already processed like this?

Not everyone was on the same page when we tried to start the because it was felt combative community vs designers.

Knight Foundation (from irc) this exists: http://www.knightfoundation.org/articles/knight-news-challenge-libraries-awards-16-million-support-innovative-ideas And that process was based on the concepts mentioned, but for libraries. Another example for that session: https://labs.usa.gov/#research-report - This was something that 18F did to analyze barriers that existed that prevented people from accessing gov't resources. All of the research was conducted in public libraries across the US. third example: Methodology: https://labs.usa.gov/files/FFD_Research_Methodology_v11.pdf

(IRC) I'm on a listserv that has many people who participate in open source projects where they discuss best practices and share ideas. It might be useful for people interested in this stuff: https://lists.freedesktop.org/mailman/listinfo/foundations (IRC) If people keep insisting something is scary, it'll only make it scarier. But going up to the communities - any of them - needn't be scary at all. Just go somewhere, ask a question. Some people will respond. Some won't. Use whatever useful information you can get out of it.�� And if anyone DOES attack you, that's on them. They're being dicks. It happens.�� Don't take it personally, just disregard them.�� And usually, people aren't dicks unless they're actually rather upset already. Usually they're bloody helpful. If you're going to them about a problem they've been dealing with all along, they may even get rather excited about it.

Fundraising has long been involved in creating loathed design output. Any such process that were eventually created, we would have to submit ourselves to. The more data-driven a discussion is, the less room there is for ego.

[?] shortcut from data to decision. Transparency will allow people to understand those [routes] shortcuts. Limitations with the design team which is resources.

Community Wishlist for UX/UI? How to utilise our existing systems whilst creating new systems to bring in new resoureces. Phab has an API that we can utilise to incorporate input from external sites.

How about using QuickSurveys for this?

If providing links on everypage is to much. Use analytics to figure out where a problem is.

You need to go to where the people are. Using multiple communication streams (Facebook, Twitter, Whatsapp etc.) However, fake accounts and very specific demographics in these places is an issue. Also, we shouldn't entirely shield people from how our sites work. We shouldn't abandon who we are.

There are limited resources. Volker was part of a team with a feedback loop and the tool essentially got shut off because of too much feedback/low quality input.

This is not about a UX/UI hub, the ideation hub was what came next.

This year's community wishlist was good, because volunteers saw the results of last year's, and had more belief that it led to results.

What are we trying to achieve?

Managing expectation around community participation is necessary. Not so many ideas will actually be incorporated in the end. How do we scale that engagement? Design is as much about saying no as about saying yes. Better documentation about declined ideas. Dealing with overhead

Wikimedia style guide, to lower the barrier to entry to contributing to design

(IRC) Re: "how to incorporate our larger audience" - I suggest just talking to people. Like this. And on-wikis and mailing lists and whatever. Go pester folks. Wherever. Not that I can actually suggest anything since there's no real connection between this channel and the session. STOP FOCUSING SO MUCH ON IDEAS. Ideas aren't process. Get people involved in actual process, in problems, in what's needed, and how to determine what's needed.