Guillaume Paumier's weblog » Design

Scaling up Software development for Wikimedia websites (Part I: Human resources)

Guillaume Paumier — Thu, 04 Mar 2010 19:57:44 +0000

During the past few weeks, I have been thinking about a more structured way to manage software and product development within the Wikimedia community. The result is a list of ideas and recommendations I have compiled and submitted to the relevant staff members at the Wikimedia Foundation. I am also publishing them here in order to allow for a wider feedback. This article is the third of a series dedicated to this topic.

Disclaimer: The content of this article reflects only my personal opinion and is not an official plan or communication of the Wikimedia Foundation.

User research is critical in order to understand the users and design products that make sense to them. (CC-by by Danny Hope)

I am not going to give specific advice about how many developers the Wikimedia Foundation should hire: there are other people more knowledgeable about how many we need, and what they should work on. However, there are other key positions that I think are need to scale up.

Our human resources are currently focusing on what happens after the code has been written: we review it, we try to ensure quality, we try to automate testing, we file bugs, etc. However, there is little preparation before the development is actually done. This has led to a developer-driven design, resulting in an interface based on the implementation model. We need a more systematic approach to User experience and development management if we want to scale up properly.

Product management & Design

In the Software development world, Product managers and Designers are the most common bridges between users and engineers. Product managers identify the needs of users and prioritize features & improvements; their goal is to translate the users’ experience and feedback into explicit requirements to meet the users’ expectations. It is then the role of the designers to create innovative, well-thought solutions to address these issues and meet the requirements. Finally, developers provide feedback about the technical feasibility of these solutions, and implement them the best way possible. This is of course a simplistic summary, but it helps get the point across.

“Designer” can have a lot of different meanings. A lot of people think that “design” is just making things pretty. When I talk about designers, I think mainly of Interaction Designers, i.e. people who design solutions to improve the user experience and the way the product interacts with the user.

The community of MediaWiki users is amazingly large, partly because they include participants from all Wikimedia Websites. Similarly, MediaWiki also benefits from a large base of volunteer developers. Product managers and designers have been the missing piece in this picture; their bridging role is critical, simply because there aren’t any volunteers to take up this task. Admittedly, some users are also developers, and some developers keep themselves informed of the users’ wishes. But without product managers, clear requirements & prioritization are missing. And without designers, the technical solutions created by the developers don’t meet the users’ expectations and mental model.

In my experience, developers prefer to focus on the actual development and rarely enjoy meta-activities related to it. They usually dislike project management and writing product specifications, and rightly so: it is not their job. However, a successful software product strategy cannot rely only on development. We benefit from a large community of volunteer developers, but we lack management & design resources; it is the role of the Foundation to supplement this lack. It doesn’t mean we shouldn’t expand our development team: our number of paid core developers is ridiculously small. It only means we should also invest where the weakness lies.

Recommendation: Recruit Product managers and Designers to strengthen the development cycle of our technological platform

Research team

The Multimedia usability project has relied heavily on initial research in order to gather as much information as possible about users and their goals. A lot of useful information was already available, but a lot of specific metrics were also missing; collecting and analyzing them took a lot of time and it will still take months to get all the metrics we need. Research is critical in order to make the right decisions, especially about design. Research is the only way know our users in order to make the best design & management decisions. Good research is the best basis on which product managers, designers and developers can then respectively specify, design and build awesome solutions.

Right now the only researcher we have is Erik Zachte as Data analyst, but his job seems to essentially focus on providing operational metrics. While this work is much needed, we also need some more specific data on a case by case basis. I see at least three other positions needed:

A UX research specialist, who would conduct regular in-house low-cost usability testing, and generally manage UX studies
A Metrics engineer, who would develop integrated metrics in the software and be able to extract specific information from the database on a case by case basis.
A Community specialist, with a good knowledge of social psychology and online interaction, who would especially focus on improving the interaction between participants by identifying the community issues and proposing ways to fix them.

Recommendation: Build a Research team to guide design & strategic decisions about our technological platform

Volunteer developers

We benefit from a fantastic community of volunteer developers, but we underestimate their potential; I think we are not doing enough to support their work and engage them into our activities. In 2007, the Foundation hired Cary Bass to try and coordinate the large pool of volunteers willing to help us with meta activities. Similarly, we need a Dev community manager to care for our volunteer developers. We need someone who knows the developer community very well, and knows their strengths and weaknesses in order to find the right person for each job. We need someone who can help orient new volunteers, organize real-life meet-ups and manage projects such as the Google Summer of Code.

Recommendation: Recruit a Community manager to coordinate the efforts of volunteer developers.

Wikimedia User experience programs: a systematic approach

Guillaume Paumier — Thu, 04 Mar 2010 15:06:55 +0000

Disclaimer: The content of this article reflects only my personal opinion and is not an official plan or communication of the Wikimedia Foundation.

A Japanese teapot. Friends of Donald Norman will understand. CC-by by Denis Savard

Investing in UX is a Good Idea™

Over the years, the design of MediaWiki has been solely driven by software developers. This has caused an unfortunate technology-based approach of the front-end and the features (implemented or missing), relying mostly on the implementation model. The consequence is that the interface & features are too far from the users’ mental model. The Wikipedia and Multimedia Usability projects have tried to address the most pressing concerns resulting from this hiatus between the software and the users’ expectations.

For all these reasons, I am really happy to see the Wikimedia Foundation investing further in User Experience (UX). However, I see little added value in having an UX department separate from the main development cycle. There are at least two reasons to keep them as one.

UX should be a systematic approach

A more systematic approach is necessary in order to improve the usability of Wikimedia projects perennially; good, usable design needs to happen before the actual implementation of any feature, in the early stages of the product (or component) development. Otherwise, we will always be running after the train, and never catch it. A separate entity made sense when these UX programs had a specific scope and time frame, but it was because they were tied to specific grants. In a more permanent setup, I see no reason to separate UX programs from the “regular” development processes; targeted actions can be carried out by specific projects inside the development team, rather than by a separate team altogether.

Everything is UX

More generally, all the activities of our Technology department are about User experience; everything we do is UX. Software development aims to fix bugs, develop new features, improve others, and remove hindrances. The sole goal of all of these activities is to improve the user experience by making the software better and closer to users’ needs. Even Operations are about UX: the goal of the Operations team is to make sure the information can be accessed reliably and reasonably fast by an audience as large as possible; in short, the point of Operations is to ensure we actually provide a user experience.

As a consequence, I recommend to make UX a systematic part of the product or component development cycle, not a separate parallel entity.

UX & IxD news – 23 November 2009

Guillaume Paumier — Wed, 25 Nov 2009 08:26:08 +0000

For a few months now, I have been maintaining a newsletter on my weblog in French called “Actualités Wikimedia“; it consists typically of very short stories and links about news of the Wikimedia universe that I find noteworthy. Part of these news come from RSS feeds in English that I follow; I summarize them in French in order to bring them to a larger audience.

I also follow another set of RSS feeds related to User experience (UX), Interaction design (IxD) and Usability in general. Until now, I have been reading them for my own benefit; but with my new job, it makes sense to pick a few interesting pieces of information for Wikimedians who want to better understand the work of the Wikimedia usability team(s). As a consequence, I will try to maintain a “UX & IxD newsletter” on this weblog, starting with this one.

Japanese Cast Iron Tea Kettle. Friends of Donald Norman will understand. (CC-by by Steven Depolo)

User research

What is the point of user experience research? It may seem obvious to any designer, but it is harder to explain to clients or, in my case, to the Wikimedia community. People who are not familiar with interaction design and product development in general often have a hard time understanding why it is critical to “lose” time in research (it is really “invest”) at the early stages, even when the course of action looks so obvious. David Sherwin provides a “cheat sheet” to explain the value of user experience research in plain English.

Can You Say That in English? Explaining User Experience Research to Clients, David Sherwin, A List Apart, 3 Nov. 2009.

What are the benefits of using personas in product design? Personas are fictional model users based on behavioral patterns and goals of real users that we have studied. More than just stereotypes with a stock photograph stuck on a board, they are very much like other scientific models based on experimental data. As a trained scientist and a follower of the Cooper methodology, I make an intensive use of personas for my work on the Wikimedia Multimedia Usability project. Despite their broad use in design teams, few studies have tried to assess the actual effectiveness of personas; Frank Long has now published such a study.

Real or Imaginary: The effectiveness of using personas in product design, Frank Long, Irish Ergonomics Review, Proceedings of the IES Conference 2009, Dublin, 20 Nov. 2009.

Design principles

Let users explore and discover your website. There is a trap MediaWiki developers easily fall into: the interface of MediaWiki (and, as a consequence, the one you see on Wikipedia and Wikimedia Commons) is cluttered by dozens of unnecessary links and verbose descriptions. On the other hand, the software is so complex that a lot of features remain hidden even to established participants. What we need is a simpler interface that provides the relevant links and hints when appropriate, and at the same time empowers and encourages users to be bold and explore the interface. Amber Simmons provides a few pieces of advice on how to improve discoverability in order to make websites more explorable.

You Can Get There From Here: Websites for Learners, Amber Simmons, A List Apart, 3 Nov. 2009.

Product implementation

A babelfish for designers and developers. In the world of software and website development, it is not uncommon to find designers and developers working together. This is for instance the case with the Multimedia Usability project, where the core team is comprised of two people: me and a software developer. However, communication between designers and developers is not always easy, because of their different backgrounds and perspectives; it could be compared to chatting in a foreign language. This is something I have also experienced during my previous work as an interdisciplinary researcher: I was a physicist and microtechnologist working closely with chemists and biologists. In her latest article, Theresa Neil provides some good advice in order to facilitate the communication and collaboration between designers and developers.

Designers vs Developers: Coming together to build the best RIAs, Theresa Neil, Designing Web interfaces, 10 Nov. 2009.