Learning patterns/Designing and developing for an active, existing project
What problem does this solve?
editActive projects, such as the English Wikipedia, have difficulties with usability or missing features that most everyone accepts as bad or have developed clunky workarounds for.
This can lead to someone trying to fix it. Maybe they do considerable research and development, maybe they have entire teams behind it, lots of hype and funding, copious project management, etc.
Often it fails. A product is developed, maybe even deployed, and then the entire team moves on and it turns out it doesn't even work on other projects, or solve the problem at hand, or work for the more active users.
There are various things that can lead to this:
- Insufficient understanding of the affected scope of the project (users, workflows, etc)
- Insufficient investment from project leaders (a team is only budgeted set time or resources to work on it)
- Insufficient investment from affected users (due to lack of outreach, apathy on their part, or insufficient time to get buy-in)
- Insufficient integration of research, design, and development resources (these need to work together throughout the project, and remain at play regardless of the stage)
- General incompetence (if it turns out this is your problem, get a new team maybe? Or try working with a less hopeless project?)
- Difficulties involving arcane technical infrastructure such as the MediaWiki parser
What is the solution?
editResearch is the first step in development and design. By itself it's tedious and daunting and doesn't always look good on paper. Higher-ups need to accept this as necessary, and also be able to recognise when this really doesn't work. We suggest hiring higher ups who are qualified in this to begin with.
Research is also the second step in development and design.
Research is actually every step in development and design, or should play some part in them. Each stage should have basis in what has been found, even if what has been found is that we haven't found anything and should keep looking.
In order to effectively design for an active, existing project, the key is to learn about it. Learning is done by doing research and talking to people and coming up with really depressing numbers about what currently exists and what users expect that make you want to go punch people in the face. This is fine. This means you have a problem you can solve through design and development.
To do this, you need to be flexible. You need to be able to budget the required time and resources to do this ahead of time, but also be able to change and adapt when new things come up. You need the scale to expand the longer the project goes on, starting out small on a limited product, working with the users on a larger scale than what you have, growing as the project progresses.
Example: WikiProject X started with research. We were trying to make a new and improved WikiProject experience for the English Wikipedia. So we researched to see what was done in general with WikiProjects, so we could then do that but better. We started with a huge list of everything every possible one did (or a representative subset, at least), and built up statistics and stuff.
We asked people what they thought.
We made a prototype just doing some of the basic stuff.
We tried it.
We made another prototype doing the same basic stuff more intelligently.
We did some vaguely related research and discovered some things about how utterly dead most WikiProjects were.
We made more functionable prototypes. People gave feedback. Tools were developed.
We now have prototypes that are fully usable and contain actual tools.
This is success-like.
But we need to keep working on it.
It's important to not just drop projects prior to completion, even if you are already seeing results. Like antibiotic treatments, products developed for these wikis need to be completed sufficiently in order to be made stable and sustainable long-term, or they may do more harm than good.