Talk:Design/Statement of purpose

I like this statement a lot and particularly approve of the prominent inclusion of “joy,” because even in wiki software, good design does more than just provide maximum utility. But I think there is one subtle but important thing missing here.

In addition to making things useful and beautiful, good design is a form of communication. In particular, design communicates values, attitudes, and a sense of the intended audience. Is your company edgy and exclusive? Boring and bureaucratic? Aimed at the mainstream, or at the elite? Wordlessly, design communicates these things.

So for me, the thing that's missing here is our values. And it actually goes beyond just communicating them. Values are part of the process, because when we make decisions, we frequently work to align users' immediate requests with our understanding of the movement's highest goals. This can be a tricky area to talk about, but if a Statement of Purpose is intended to help guide and explain decisions, then it might be worth including some reference to this. E.g.:

“Our goal is to ensure that Wikimedia products and communications follow a design process that's centered on the user and guided by our movement's highest values and goals. Based on research to understand people’s needs and motivations, we explore solutions that meet those needs and express our common aspirations.”

For what is worth: Technical Collaboration Guideline/Principles.

When reading this, two words jump out at me as missing: consultation, and simplicity.

Consultation as that's something that has always caused problems in the past: changes being made without adequate consultation ahead of time, or even plans being made without adequate consultation. That's a bit different from collaboration, which comes after consultation (and is good to see mentioned in its own right).

Simplicity is probably a bit more controversial, particularly within Wikimedia as we end up catering for every viewpoint rather than trying to focus on what's essential. Hence even the name 'Wikimedia' (and all of the other names things in the Wikimedia movement go by), while 'Wikipedia' is the brand that everyone knows. And hence big lists of links in sidebars, as another example. But simplicity in both form and function is quite important to make things user-friendly.

I hope those suggestions help. :-)

thanks Mike for the hints :). How do you think we can incorporate the two themes, simply, into the statement? Actually simplicity could fall under usability, while consultancy could be part of transparency. What do you think?

I'd consider adding them as separate points. If you think they fall under existing points, then it might be worth expanding those existing points a bit.

Regarding Mike's comment about "consultation" being missing: To me, the language here about "a transparent and participatory process" covers that idea nicely. "Transparency" refers to outward communication, while "participation" invokes the idea of user input. Just as the statement mentions "research" without spelling out that we do usability testing, it seems appropriately high-level here to promise community participation without enumerating the specific modes.

Change, "We make sure that products and communications in Wikimedia projects follow a proper design process" to "We make sure that products and communication in Wikimedia projects are well-designed."

Thanks for putting this out there.

One more (I know you said you preferred no word smithing, but that's what I have right now). Use it if it works for you. If not, no problem. "Design at Wikimedia aims to make sharing human knowledge easy and joyful for everyone."

I think "easy and joyful" are actually good conceptual guidance. After I offered my first suggestion, I was reviewing my editing contributions and there is still so much information and so many portions of the interface that I don't yet get. Sure, I will slowly take the time to understand it over the years, but I still think it would be better if it were easier. Joyful never hurt either. That's why those concepts seem like good guidance to me.

Thanks for your input, @Annaproject.

I'm happy to hear that you consider "easy and joyful" to be a good conceptual guidance.

Regarding the word smithing, although we wanted to keep the discussion at a higher level, any change that helps making the text simpler is totally appreciated. So thanks for that too.

Regarding "follow a proper design process" vs. "products are well-designed", it depends on how much we want to put the focus on the result or the process.

The result ("well-designed products") is what ultimately better aligns with out goal. However, it may also e understood as our role being similar to an oracle or judge dictating what is or what is not well-designed. By emphasising the process ("follow a proper design process"), I think we emphasise the idea of helping teams in the path to get to those well-designed products (although that last part may be a bit implicit in the statement).

The document appears to define the stakeholders as

   Audience heads
   Product managers/owners
   Software engineers

Where, if anywhere, do actual users fit in to this process? What is the proposed plan for user engagement as the concept, planning, design and specification stages? Are users regarded as co-creators of the design product, or merely passive consumers of whatever the process happens to produce?

PS: What exactly is an audience head?

Fair questions, Rogol. Thanks for asking for clarification.

Where did you spot "audience head" in this particular document?

We are talking about a human centered vision, which, by definition, puts the user, at the heart of the process (hence this statement of purpose, to actually acknowledge that). Our "users" vary from contributing community members to casual readers, and with a wide range of shades in between (casual contributors, addicted readers, etc). When the document mentions research and collaboration themes, this entails that user research is conducted and collaborative discussion/decision-making processes are applied, while keeping in mind, that collaborative decision making process could be experimental/changing, based on the variety of users mentioned earlier, where in any case, we would make the process as transparent as possible (and we already mentioned transparency).

It is in the linked Team Practices Group/Design engagement/Post-interview roadmap. Do you accept that list (which I have quoted directly) as the statement of the relevant stakeholders?

You say that you will put the user at the heart of this process. Very well, then how?

"Very well, then how?"

I think they say how right above your comment in this sentence: "When the document mentions research and collaboration themes, this entails that user research is conducted and collaborative discussion/decision-making processes are applied".

Does that answer your question, or is there more that I am not getting?

"users" seems really different than "user research is conducted and collaborative discussion/decision-making processes are applied".

The first means these are stakeholders.

The second means these are final users, than serious research will be done by people in the know to understand what they want, filtered by research call for feedbacks, polls, automated messages on the village pump more than by organic discussion.

In general, the audience head, is someone who manages a team whose work is user facing, so people related to product, fundraising, and communications for example. The people you mentioned are directly related to product work, and the design work, however, in a community based movement, stakeholders are more broad, otherwise, we wont have this conversation around a draft of statement of purpose, while editing it as we share.

As mentioned, human centered design, by definition, puts the user in the heart of the process, it is kind of a standard process, where we will not reinvent the wheel. Thanks.

Thaks for that. So all the stakeholders listed in that subpage are internal, so it cannot be complete. What and where is the accepted complete list of stakeolders?

I regret to say that simply repeating the slogan that users are at the heart of the process does not answer the question "how". How will that laudable ambition, and the design philosophy you mention, and the standard process you propose to adopt, actually be put into practice by the WMF? What form do you envisage for the engagement? What will you actually do in the real world? Surveys -- closed or free-form, opt-in or opt-out, public or by invitation? Wiki pages -- which wikis, which pages? Face-to-face meetings -- where when and with whom? Mailing lists -- new or existing, open or closed, moderated or unmoderated? To adopy your metaphor, there are many wheels that have been invented, now you have to choose which ones to use and where on the vehicle to put them -- and you need to work with the community on that choice.

@Rogol Domedonfors, I actually think that these are really good questions. It's clear you really care about designing for the user. If not written directly into the statement of purpose, @Awjrichards (WMF) answering some of these questions can only make design better. But perhaps those answers come at a different stage?

@Rogol Domedonfors thanks for kicking off this thread. The document you linked to regarding stakeholders (Team Practices Group/Design engagement/Post-interview roadmap) is not intended to outline the stakeholders to WMF design. Rather, the list of stakeholders articulated there are those identified for the process we've undergone of defining the statement of purpose for design. I think you are correct that it is incomplete and currently only references stakeholders internal to the WMF. I've updated the document to that effect.

It's important to note that this document (this draft statement of purpose) is not intended to articulate specific actions that will be taken - it's not intended to answer the "how", which from your comments I am understanding to be your principle concern (am I grokking that right?). This document is about the "what" - what is it that design at the WMF is attempting to achieve.

As for the "how" piece in regards to user research, currently each product team approaches this as makes the most sense for them in their product area. But at a high level, much of the user-centric research that happens at the WMF happens through our Design Research group. You can find specific details about their "how" on their linked page.

Once we've clarified the "what" question, we will be reassessing the "how" question more broadly - what needs to change for the design group to be able to achieve what it's setting out to do? In other words, what needs to change in the "how" to help us get there?

Do we have more specific plans regarding accessibility. Currently there's no mailling, as far as I can find. Accessibility is a broad topic, for example using free license, and projects like Wikipedia Zero might be presented as accessibility facilities. There are also attention which is given to places where events are conducted, Esino Lario for example made huge developments to make the site accessible. But surely here as we are talking of UX and design, this is more focused on web accessibility. By the way we have a MOOC on the French wikiversity regarding accessibility and the English version seems to have some material. Please share whatever this message inspire you. :)

Good point, but do you think usability already covers accessibility?

Well, semantically speaking, you certainly can say that usability covers accessibility (and you may do the reverse statement as well I guess). Now there are topics that are clearly more an accessibility subject (is the page content browsable with a braille terminal) and other more on the UX side (is the edit functionality of the mobile app convenient enough). Having something which is convenient for most users can sometime clash with accessibility principles. Of course, as much as possible, it's preferable to have a solution which works better for everybody. So, to my mind, having dedicated mailing list and teams for both subject would make sense.

Thanks for the suggestion and perspective, @Psychoslave. The main purpose behind the conversation we're trying to have now around the draft statement of purpose is to understand whether or not the themes design is trying to address are the correct ones, and whether or not they are adequately reflected in the statement itself. Suggestions about specific and practical actions to take around those themes are certainly valuable, but for our purposes here, I am curious: do you think accessibility is adequately reflected/addressed in the statement of purpose?