What I've learned from working with ProleWiki

And what I can teach you when it comes to organizing people

I’m a designer by trade, with more practical experience than theoretical.

In 2020, I joined the nascent ProleWiki two months after its founding when I read my (soon-to-be) co-admin’s essay On Drug Use. Prior to that, I thought of ProleWiki as an interesting project, but not one that I necessarily wanted to join. That all changed when I read that piece; that’s when I realized the potential behind that platform.

Back then, everything was still to be decided on ProleWiki. It started as a loosely-defined project of which only one thing was sure: making a wiki for Marxists. This is actually a great design choice, and we’ll get into that later.

I joined the administration in early 2021, along with several other editors, as a way to help develop a clearer line for ProleWiki and formalize what its role could be for people around the world.

Personally, I think that design overlaps a lot with marxism. If we hold that everything is dialectical (and it is), and if we hold that everything exists in the material world (it does), then we could refine the saying as: “Design is just a subset of Marxism”. From there, we realize we can apply design to our organizational work.

… and if I lost you by talking about dialectics, don’t worry: I’ll explain what that is soon in a way everyone can understand (and will put a link to the article here). It won’t prevent you from understanding the rest of this article which will be entirely about design.

Since my early days on ProleWiki, I’ve stayed on the administration through the highs and lows, and have developed features, principles and ideas of my own on the website (such as our new Portals). Today, there’s only two admins coordinating everything: me and my co-admin Forte, the aforementioned author of the essay above.

The reason we have been able to grow so quickly — not just in term of what we offer but also in terms of how many people visit and talk about us — is because we follow a design approach to our work, which structures and focuses our problem-solving and solutions on what is actually impactful.

Here’s some of the things I learned from this work which I’ve been doing for 3 years now, and which I hope you can learn to apply in your own organizing or outside of it.

Everything is a problem with a solution

I actually find this very freeing. If there’s only two parameters, and you have to act within those two parameters, it also reduces the chances that you start going the wrong way. It keeps you focused on the only path that you have before you.

In design, everything can be boiled down to a problem. And every problem, by definition, has a solution. You just need to find both the actual problem (this is where design thinking can help) and then one solution. Not the solution — just the best one you think you can do under your circumstances.

There’s always limiting circumstances: time, skills, budget, etc. are limiting factors. The point is to be realistic with what you have and apply those available resources where they will be most impactful to the best of your ability.

Learning to identify problems and then think of solutions is a process and is actually two different skills. They come with experience and with reckoning with reality — you can’t fake your way to it, it has to come from actual situations you find yourself in. But, you shouldn’t think of solving problems as a professional skill only. It can help you in your daily life as well.

I myself have become solution-oriented in my daily life, and while I don’t want to claim this approach will work for everyone, it does help me stay focused and not start overthinking. When things get tough, I think to myself there has to be a solution, I just have to find it. It’s pulled me out of difficult situations more than once.

Let’s think of this simple situation: you’re thirsty. Problem: you don’t have anything to drink at home. Solution: run to the store and get something to drink.

That’s a simple problem with an understandably simple solution. But the problem-solution process can also help with much more complex problems, and we’ll see in the next sections how you can achieve that.

Once we know what a problem is and know when we’ve found it, we can start figuring out ways to get there.

Learn to think like a designer

Design thinking has been rationalized into a very structured process that goes through five steps. In simple (but seemingly abstract) terms, it goes like this:

1. Understand your audience. Put yourself in their shoes — it’s easier said than done! Ask yourself the questions they would ask themselves. Take the time you need (it can be hours or it can be days) to really understand their situation. It’s important to listen and ask questions. At this stage, you’re not even thinking of the problem yet.

2. Define the problem. Once you understand who you’re dealing with, isolate the problem they face, and the right one. Sometimes, people might think they have one problem but it’s actually something else entirely.

3. Ideate. Start thinking of solutions. Measure how realistic they are and how impactful they would be (we’ll get into that), and keep one solution to try.

4. Prototype. Make your solution tangible, actually bring it into the world. It doesn’t have to be perfect, it just has to exist.

5. Test it. Bring your solution out in public, let it play out, and then see what comes out of it. See if it succeeds, or fails.

It’s important to note that sometimes you might go back a step. These 5 steps are not rigid; as you get more acquainted and comfortable with the process, you’ll know when to break the rules and when you’re going the wrong way and should go back to the drawing board. Sometimes, you might test your prototype and realize you got your audience all wrong, and you use that feedback to refine what you thought of your audience. It’s all part of the process.

Let’s illustrate all of this with an example. Workers at the Tricoins coffee shop are not happy with their conditions. Their manager is not allowing them to sit down even for a second, and wants them to always be doing something, preventing employees from taking breaks. Their common complaint is, “I wish I had another manager, a nicer one!” You take a good long look at the situation: how the store operates on a day-to-day-basis, what other things the workers have to say, what the manager has to say. Yes, even the manager needs to be interviewed to get a full picture of the problem! At this stage, you can’t judge the situation you’re facing as it might lead you to the wrong solution. You must take things as they are, without judgment, and get a full picture, as full as you can get it. You have understood your audience.

You quickly realize the problem is not the manager but the franchise itself. The franchise owner is putting a lot of pressure on the manager to meet unrealistic quotas. Replaced the manager will not change anything, they will be pressured to the same expectations. You have identified the actual problem: the franchise owner needs to chill.

Now is the time to find solutions and ideate. You could talk to the franchise owner and ask him to be nicer to his employees. Well, this seems like an easy enough solution that doesn’t require too much effort (in money, time, labor, etc.), so let’s try that. You talk to the owner and he doesn’t care about any of the employees’ problem, he just wants to see the profits rolling in. You’ve tested your solution and it was inconclusive, and so we go back to ideating.

What else can we do? Well, let’s look at the problem some more. We realize the employees don’t really need a manager, the manager is just here to meet the quotas set by the owner. So how about the manager becomes an employee like everyone else, and the store speaks as one against the franchise owner’s interests? We’ve ideated something else here.

You write down a unionization plan: you’ve prototyped a solution. Then, you present it to the employees and they all agree to unionize.

The boss has no choice but to accept this decision (in reality, he will try to fight it and this will likely have to be settled in court, but for the purposes of this example let’s say they were able to unionize while the boss was distracted on his vacation to Mexico). He can’t fire the entire store for unionizing and if he did, he would have to re-hire an entirely new team from scratch. We’ve prototyped the solution and are now seeing it play out, testing it and waiting to gather feedback.

You come back a month later to see how the store is doing. Now that they have no manager, the employees are not being bossed around anymore and are much happier. They have very few complaints now. You’ve tested your solution after taking the appropriate amount of time for it to play out, and saw that it worked out great. Congratulations! And if the employees still have some complaints that need addressed, you can apply design thinking again and again to tackle all the new issues that have come up now. There is potentially no end to it.

The beauty of design thinking is it can apply universally; I’ve yet to find a situation where I couldn’t apply this process. It’s just a matter of finding the right problem, and everything follows.

Learning design thinking is not easy. It’s not really something you can just read about and understand like you might math or physics; it takes practice to internalize it and become comfortable with the process. Remember: the difficult parts are understanding your audience and bringing out the right problem. Finding the right solution is often much easier once you have a clear, coherent problem figured out. So focus on that first.

Getting ready to sprint

Once you start to get design thinking and see results, you can try a design sprint. A design sprint is the 5 steps of the design thinking applied over 5 days, with one step being taken each day. This is a very efficient way of putting out a prototype (a first version that has the bare minimum viable features which you can improve on later), as you must have something out in 5 days.

On ProleWiki, we are starting to use design sprints to focus our efforts and avoid people naturally losing interest. As our communication is entirely online, it’s very easy (I’m guilty of it too) to lose interest in a project you’re involved in. Then it gets revived two weeks later and everyone has forgotten what we were talking about or why we were even doing this project in the first place.

Being able to manage expectations, telling people clearly “if you join this sprint, we expect you to be active every day (but only for 5 days), so if you’re otherwise busy, please don’t feel forced to join” yields much better results. We will go into this in a later point, but I much prefer being in a small but active team of 3 than a big but inactive team of 8.

I’ve done design sprints in companies too, and there’s a whole methodology for each day (there’s an actual book on it, titled Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days). Personally, I think it’s fine to apply the methods the first times you try a sprint but as you become familiar and comfortable with the process, you will learn when to break the rules. And isn’t that what life is all about?

You can always go one step further

This is one of my own key principles. I call it the “Simpsons method”. Watch this 30 second clip real quick:

In this clip, there is not one joke, but five building on each other. First, Bart doesn’t see the street sweeper heading for him. His bike then gets caught in it, but it actually comes out looking pristine — the first and second jokes.

Instead of stopping there however, the writers have Bart happily get on his bike and start riding, but then it breaks down — third joke.

Then, he looks back at the driver who is laughing ominously, indicating he actually ran over Bart’s bike on purpose; the fourth joke.

Finally, as the driver is looking back and laughing, he accidentally climbs on the sidewalk and falls down the subway station, the final joke.

This is the Simpsons method. They could have stopped at the first or second joke and moved on with the episode, but they applied the principle (back then at least) that there’s always an extra step we can take to make something even better. No matter if it’s a small or big step. It’s just a matter of finding it. 80-90% of a project is easily done, the hard part is getting the remaining 10% put into it when everything is getting close to perfect.

Bring everything to its logical conclusion would be another way of putting it. Carry your ideas to term when you actually practice them.

With that said, you shouldn’t fall into the trap of perfectionism.

You don’t have to be perfect, you just have to exist

This is something I often repeat to people. Nobody expects us to get it just right on the first try. We are often our own worst critic.

In design, we often talk about the MVP — not the most valuable player, but the Minimum Viable Product. As the name implies, the MVP is essentially the most basic thing that works.

Let’s say you’re setting up a party (the organization kind). You don’t need to think about your statutes just yet, about your committee, about when you’ll hold the general assembly and where… you just need to start getting out there and do something valuable for the people. This is the MVP. Later, as your party evolves and grows, you can start slowly setting out to get what you need as it comes up.

The same principle was applied to ProleWiki. When we started out, we didn’t really know where it was going to go or how it was going to evolve. We tried different things; for example, early on most editors were invited to become administrators to try and get them interested in the project again (as with most projects, interest dwindled soon after the initial first few months). This worked out terribly, as we were simply not ready to accept so many admins: we didn’t have principles fleshed out yet, we didn’t really have a line we wanted to follow, we didn’t even really know what our purpose was yet (today it’s become quite clear, and I’ll probably talk about it in another article).

But it’s okay. We didn’t have to be perfect from the start. What matters is we exist and, as time goes and we get feedback, it becomes clearer to us where we deliver value to people, why they visit ProleWiki and what they want to get out of it.

Our model is to cross the proverbial bridges when we get to them. For example, for a long time, the administrators approved or rejected account requests up to their best judgment. In late 2022, as we grew more active and cultivated an active base of editors, we started submitting account requests to the editors for a vote instead, and have been doing it ever since, thereby steadily improving democracy on ProleWiki. We recently voted to name a library and essays space maintainer, who are responsible for managing, maintaining and growing their assigned space, thereby allowing us to grow these two “parallel” projects within ProleWiki on their own. But a year or two ago, there would have been no point in having a library maintainer because it wasn’t yet a big or strong enough part of ProleWiki that it really needed one.

Our material conditions in the present moment dictate what we focus on.

Don’t hesitate to admit you’re wrong

This is difficult to learn, and sometimes we don’t even realize we are blocking a solution because of our own ego. I’m guilty of it too, I’m sure.

But understanding where you went wrong is extremely valuable. It allows you to learn and grow, not repeat the same mistake, and ultimately allows you to find the correct solution, which is what you want if you’re solution-oriented like me.

For example, a problem we’ve seen on ProleWiki is that not many people are aware they can actually request an account and join the editorship. To help increase the amount of requests we get (increasing the conversion rate from visitor to editor, which is a division expressed as a percentage ratio), I designed a button that would appear on all pages for non-logged in users:

The forbidden button on ProleWiki

When clicking this button, which looks like our own “Edit” button, the user is taken to a page that explains one needs to request an account if they want to edit or correct a page, and a link is provided to the account request page.

---

Let’s quickly apply the design thinking process to this button though, just so you get a better grasp of how the process works.

Initial situation: we’ve noticed we don’t get a lot of new account requests, and we would like to make the editorial team bigger (this is one of our permanent goals by the way)

1. Understand why we don’t get many requests. From surveys, analytics and talking to our community, we realized a lot of people don’t even know they can request an account. Previously, we also thought our vetting process was too long. But looking at the data (how many visits we actually receive on the account request page), we saw this was actually the problem: the request account page is simply not visited a lot, which likely means people don’t know how to find it.

2. Decide on the actual problem: people don’t know they can request an account and join the editorship.

3. Ideate: what can we do on this front to improve the number of account requests? Place the account request functionality front and center. A button is simple enough to add, and it will show on all pages. Let’s try that.

4. Prototype: create the button and deploy on the website.

5. Test: after a month, see if our numbers improve. If not, go back to previous steps as needed and start over from there.

---

I let this solution play out for a month to gather data before analyzing the impact it had, while sometimes making tiny changes (like the wording on the button) just to see if it made a difference with the numbers.

What I found was that people didn’t really care about the “Make a correction” button. My hypothesis was seemingly wrong; it didn’t increase conversion rates (more account requests) and most people clicked back when they reached the in-between page that explains why one needs an account to edit.

But that’s okay. At least now we know what doesn’t work, and from there we can infer more data than is explicit to design a better solution.

Learning what didn’t work is part of the process

It’s important to know what didn’t work so that we can get the right conclusions. From the “fake” edit button, we learned that the in-between page was a barrier. We learned, when looking at our analytics, that most visitors to ProleWiki didn’t even click on it — meaning most people on the website want to consume content instead of creating it; less than 1% of our visitors have clicked on this button.

This is still valuable information though. It will allow us to craft a better solution down the line (to get more editors on the team). If we know that people from our website don’t really want to edit the wiki, then we know that we should look for editors somewhere else. We know that we should change our approach too, and maybe reach out individually to people we know and think would make good editors.

These are all possible solutions that, if we decide have potential, we’ll have to try out and analyze: we repeat a process of ideation → prototyping → analyzing; this is called lean thinking if you want to look it up.

This is pretty much how parties work. We find what works and what doesn’t. We know why things don’t work.

Rely on data

Data is important to do our work. In the age of big data, we tend to think of it as numbers, analytics, big brother spying on you, etc. It’s not wrong, but data is actually much more abstract. I would define it as:

Data is any piece of information that can help us in designing a solution

It doesn’t have to be numbers. Data can be a book that you read, or a methodology that you learned. It can also be, as we just said, a failure that you’ve experienced.

Theory can be seen as data. When Lenin explains in State and Revolution why electoralism will bring us nowhere, he put it into practice and was vindicated by history. When we learn this for ourselves the first time, we have effectively gathered data passively.

But it can also be gathered actively. I’m a huge believer in surveys and getting feedback. Ask people for their opinion, and do it often. Ask party members what they think of the meetings. Ask what skills they have and where they would like to put them to work. Ask your friends what their biggest difficulties in society are right now. Ask, ask, ask. This is not only the first step of the design thinking methodology, it’s also how a party stays close to its base.

If you want to work for the people, then you need to know what the people need. This is something we all understand as Marxists, but don’t necessarily put into words. You can’t decide for factory workers, for example, what they need to improve their job conditions: they will know this themselves with or without you.

More broadly, we can simplify “accepting failure” into “learn what you can, take what is useful, and leave the rest out”.

Involve people that are interested, not forced

I would rather work with 10 committed comrades than 1000 that barely give signs of life, and I think most of us would too. But let me ask you this question directly:

A socialist party is not looking to get big to show the conventional parties that they’re the biggest. We don’t recruit people for numbers, we recruit people who want to get involved in the struggle.

I actually see some parties making this mistake, trying to get as many members in so that they can appear to be “popular”. Then, two months later, all of their members stop replying to emails and stop showing up.

This, I believe, is a problem in onboarding. The party was unable to properly capture what interests their individual members and offer them what they need.

Certainly as socialists we don’t always have the luxury of saying “I don’t want to”. But again, would you rather have someone who is dedicated in one task and does a great job at it, or someone who feels forced to participate in all sorts of tasks and half-asses all of them?

If you don’t like leaving your house but you’ll do overtime as long as you’re on the computer, then great. I won’t force you to come to protests, and instead I’ll ask you to be on the social media team. If you like talking to people but you feel like you’re pestering strangers when you ask them to sign a petition, then I’ll suggest that instead of canvassing, we could use your sociable personality somewhere else (being our spokesperson for interviews or speeches for example).

It may seem simple, but this is something that I see parties fail at all the time. They expect members to be experts in everything from the start and to not say no to anything.

It’s a problem in business too. Our “soft skills”, which is our personality and other traits we learn through experience (like design thinking), are becoming more and more interesting to employers. Nowadays, almost anyone can have a college degree and there’s thousands of people who have the necessary diploma for the job. But not all of them will get along with the coworkers. Not all of them will stay in the business. Not all of them will get the gist of the job and company in the first week.

In a non-profit setting like ProleWiki, we have the luxury of accepting whoever we want as we are all volunteers (and as such don’t have budget as a limiting factor). We started asking them what skills other than writing they have, so that we can start thinking about where they could help.

If you like making videos, we can give you access to the Youtube channel. If you like teaching, we can have you patrol the edits new editors make so you can help them with the editor, sourcing, etc. If you’re an accountant, we can have you keep our financials table updated.

There is essentially no limit to where we can place people and finding out the skills they have and putting them in the right spot is almost a skill in itself!

Having ideas is great, being able to carry them out is better

I’m a fan of brainstorming. I see for myself every day how just talking to other people can help clarify both your own thoughts and theirs. How ideas you would never have had suddenly materialize in your brain simply by engaging in a discussion with someone.

I like brainstorming sessions for this purpose. In a brainstorming session, people talk about the problem you face for 15 minutes. Someone in the group writes down all ideas, no matter if they’re good or bad, and makes sure the session stays on track. However, I’ve found that letting people talk about other things (context for their idea, a relevant story that happened to them, etc.) during these 15 minutes also often yields even better ideas afterwards. The time limit is important to make sure the session doesn’t drag on and people stay creative, but it shouldn’t be seen as a rigid session where one is only allowed to blurt out ideas and nothing else.

Anyway, this isn’t supposed to be a tutorial on brainstorming.

Having ideas is just one part of the equation. Theory without practice is just words in thin air, and practice without theory is adventurism.

Realizing that you not only have the (brain) power to have ideas, but you also have the power (permissions, resources, etc) to try them out yourself is important to form independent, creative users, which creates a strong organization.

On ProleWiki, we (well, it’s mostly me) always say that when someone has an idea they should not be lazy — jokingly — and carry out their idea themselves. Don’t wait for another editor to do what you see needs to be done, do it yourself right now. If you see a typo on a page, fix it. If you don’t like how an intro is structured, propose your own change. If there’s a big article you want to start but don’t really know where to begin, form a group with 2 or 3 other editors and start writing this article with them.

This leads not only to self-responsibility, but it empowers people too. It makes them realize they have something to contribute and their presence is valued. It engages them in labor that pays off; they can very quickly see the actual impact they’ve had. For example, a member once made a meme about ProleWiki and we shared it on social media. It eventually made its way to Reddit and we almost set a new record of visits that day. I made sure to tell the comrade about this, not so much to praise the, for their meme, but to let them know that their meme has had an impact, it has led to a ton of visits, and that this was directly measurable.

I find it also prevents the curse of having too many ideas but too little time for each of them. People sometimes approach me with ideas that we could look at (like making an app, which is gonna be a huge project). I always tell them the same thing: we have so many things that need to be done right now already, it would be better if they helped with those first. Then, once we’ve taken care of our backlog, we can look at new ideas.

This is a win-win situation: we get urgent things done, and people get involved with the project and realize that their involvement is needed and valued. And eventually, as we clear the backlog of everything we need done, we can look at adding new ideas in, including theirs.

A party works a bit differently. It needs a clear, unified line to avoid factionalism and disgruntled members working against the party. However, a party still has a strategic vision made by the central committee, and an operational side made by the members on the ground. It’s actually in this case especially that we can involve the “ground” members into strategic decisions, letting them propose their ideas for a vote. We already do this without giving it this name, and we call it democratic centralism.

How to prioritize your solutions

Mockup of our library, dated July 2023. As you can see, it doesn’t have to look great or perfect, it just has to give us an idea of what the end product will look like. The actual library doesn’t look exactly like this mockup.

How do you find which ideas are worthwhile or urgent, and which ideas can be put down to take care of later? There’s a useful tool called the ICE model (Impact, Confidence, Ease) but I personally don’t use it and I never recommend what I don’t use myself. What I do instead is prioritize based on the short-term, mid-term, long-term, and undefined-term.

I find that almost nothing is considered short-term (needing to be done urgently), and most things can be taken care of in the mid-term (3-9 months). Long-term would be 9-12+ months, and undefined-term would be something that would be nice to have but has 0 priority or takes too much effort for the return it would have.

The new Library on ProleWiki for example was an idea I had for almost 6 months before setting out to do it. The impulsion behind it was simply “Our current library is kinda difficult to navigate, we can probably make it better”. That’s all I started with.

During those 6 months, I was solely researching what exactly “making it better” meant, what I needed to take into account to make it (tech limitations set by MediaWiki), how I wanted it to look, how it was going to be experienced by the editors and the readers (two very different audiences), etc.

Eventually, we ran a small survey in which I showed a mockup (a jpeg that shows what the library page will look like once it’s coded), which was received really well, but the project went dormant again for a few more months. After I’d finally figured out how I could implement the new library, it took me a weekend at most to get the MVP out (Minimum Viable Product) and then a few more days to iron out the fine details. A month after the new library was out, we added two other card types from the big ones you see in the mockup above to save up on vertical space (especially on mobile), showing continuous prototyping like in lean design.

The new library was a mid- to long-term project. The reason it wasn’t a short-term project wasn’t necessarily because of the difficulty of making a new library (as I said, it took me a weekend once I learned how I could code it on MediaWiki). It was long-term because we already had a working library page, if a bit unwieldy (it was just a long page of text), and so we had all the time in the world to make a new library. It was not an “undefined-term” project because I knew I wanted to get it done some time in 2023 and not leave it hanging for too long, and that as soon as I got more familiar with MediaWiki and how to code in it, I could get it out ASAP.

Establishing a culture of constant improvement

All we’ve seen ultimately leads to a philosophy of constant improvement: the belief that there is always something to improve, no matter how big or small. It can be fixing a typo on your website, or it can be organizing an entire protest (getting the permits, etc). There is always something that can be done when you look for it, and all of it will have an impact. And constant improvement is recursive: you can organize your first legal protest. Then you can organize it better next time, getting the permits faster, or getting more people to show up. You can improve what you improved.

Constant improvement is, incidentally, how China (which is the fastest-growing and biggest economy in the world) works, though I’m unsure if they have an official term for it.

Culture (in an organization or anywhere else) is eventually self-reproducing. We reproduce cultural traits we inherit from our surroundings (family, friends, but even architecture, art, the music we consume, etc.) and we pass them on to others as well. It works the same in an organization. If you are able to promote a certain culture, people will eventually carry it and pass it on to the new members. While it can take some time to get started (we still haven’t fully developed a culture on ProleWiki), culture can be very powerful: don’t underestimate it. But culture is created actively. If you told punks you’re one of them at a Dead Kennedys concert where you showed up in a suit and tie, they would laugh at you. That would negatively reinforce your identity, and the next time you would get some more fitting clothes. You can’t call yourself punk if your casual attire starts at a suit and tie, it’s just not part of the culture.

Likewise, we actively remind our team (and ourselves) to constantly improve. When they notice a glitch or typo and raise it up on the channels, I’m usually the first to ask them to fix it since they noticed it.

It takes time, but establishing the right culture in your organization or projects eventually leads to more and better involvement, fewer headaches, and generally just more value delivered.

This is what working on ProleWiki has taught me in three years, and I hope I was able to teach you things as well.

This article is not what I usually write about, but I hope you enjoyed it nonetheless! As a designer, I want to bring my own perspective to my writing, and I think learning design is useful to everyone, especially those of us who want to understand the world.
Would you like to see more or less of this kind of articles in the future? Don’t hesitate to tell me in the comments!