How we redesigned the ProleWiki homepage and what anyone can learn from it
You don't need to be a designer to understand design -- promise.
If you like this article, please don’t hesitate to click like♡ and restack🗘 ! It’s a quick way to make sure more people will get to enjoy it too.
And don’t hesitate to subscribe to my newsletter for free to receive my new articles right in your inbox!
Pictured above is the current implementation (at the time of writing) of the new ProleWiki homepage, which is entering the last homestretch before being deployed on the website, replacing our trusty — but outdated — previous homepage which had been in place since ProleWiki first started in 2020.
I talked previously about what I learned working on ProleWiki, and there I talked about how I redesigned the library space (which has its own homepage) and the essays space to look more like what we think of when we think of a blog.
It was thus natural that after these two big projects, having acquired confidence in the tools of our trade (MediaWiki), we turned to an even bigger challenge: the instance homepage, the page everyone sees when they open ProleWiki in their browser.
What the data told us
The situation was thus: our old homepage had been hastily put together back in 2020, four years earlier. It was very well-made technically, there’s no denying that, but at the time there was also very little content to put forward, and there wasn’t really all this hindsight to even know what kind of content we were gonna have.
Since then, we have grown from having literally nothing (we had to start somewhere!) to these figures:
Over 30 active editors,
1000 visits every day,
Almost 4000 pages created, of which 1000 are library works.
An essays space that features our editors’ personal essays, some of which have become relatively well-known.
More and more social media profiles.
This is data, and I’ve talked about information and data before: data is the step before information; it refers to a raw fact, such as a number, that has not yet been processed and analyzed. Data has meaning, we just haven’t found it yet. Once we know what it means, data becomes information.
If I tell you a website makes 1000 visits a day, this is raw data: the number is a fact, we know it to be true, but we don’t really know what it means. To turn it into information, we need to analyze it and put it in relation to something else. Is 1000 visits a day a high number, or a low number? Well, we can compare to other similar websites. Is it growing, or shrinking? We can look at other data points earlier in time and draw a graph. With this graph, we can also do some statistical work to predict things such as future growth.
What we had readily available when we set out to redesign the ProleWiki homepage was the raw numbers that I listed above. That’s all we knew to begin with. However, one doesn’t set out to build something new with just data: between the raw numbers and the final result you see above, an entire process took place.
The design process
I coded that new homepage with one of our co-admins, who wanted to take on the challenge and start a new homepage somehow. And when we as humans don’t really know where to start, we usually start by going in head-first (I do that too with my writing!)
In this case, he started by taking the existing homepage (the one that’s now been retired), duplicating it somewhere else on the website, and modifying the code and content little by little. This was the spark we needed to start seriously looking at finally making a new homepage — we had been talking about it for over two years, but no progress had been made in it.
When I saw his first trial of a new homepage, which looked nothing like the one in the capture above (projects rarely do end up looking like their first demo), I offered to follow the design process and start thinking selectively and with goals in mind before we even touched a keyboard and code.
I’ve talked about the design process before, and I will go through it here again with this situation in mind; what you will read below is exactly what we figured out for our new homepage.
The design process is a specific process; often, I find that people don’t really know what design means — and I don’t expect them to, because we all have different interests and skills — and might call something their design process. Beyond these generalities, the design process has been mostly rationalized and boils down to five specific steps:
Understanding — understand your audience/situation and what their problem/s is/are.
Define — define the problem that this audience faces, put it into words and categorize it.
Ideate — start proposing verbal solutions that would fix this problem.
Prototype — prototype your idea into a working solution that can be deployed and actually used.
Test — test your prototype in a real-world situation, and go back to ideating and prototyping as needed afterwards until you have something that finally solves the problem.
This might seem very abstract, but it works in many situations. In fact, I’ve yet to find a situation where this process couldn’t apply. Are you currently stranded on a desert island? Let’s design something by using these steps!
Understand — you are currently stranded on a desert island and are getting hungry.
Define — the problem is that you have no food. Obviously if you had food, you’d know how to eat it. So find food, solve the problem.
Ideate — where can we get food? Looking around, we find some coconut trees. But how do we get the food down from the trees? Well, what about some sort of spear that could be thrown at coconuts and knock them down?
Prototype — Grab a stick and stone and fashion the stick into a spear.
Test — We’ll only know if it works once we try. Grab the spear, throw it at coconuts, and see how it goes. If you miss, then you’ve gathered a data point: you missed X times. If you hit a coconut but it doesn’t fall down and the spear gets stuck, then you gathered another data point: the spear may get stuck without knocking the coconut down. If you hit a coconut and it falls down, success! Our idea worked.
We may move between steps at several times; there’s no rule that you have to follow them in order and that you can’t go back once you’ve “completed” a step. The design process is supposed to be an efficient method, and if you need to move back and forth to be efficient, then do it.
I also brought back data points in this example. If you throw the spear 10 times and miss 9 times, you have data: some raw facts. If you sit down and start doing some math, realizing that you’ve missed over 90% of your shots, then you have information because you can act on it: a 90% miss rate is pretty high, and it might be worth going back to the drawing board and finding another idea to try.
We can only gather facts and data from the real world and thus information remains rooted in experience. In other words, you’ll only know something for sure after you try.
Let’s go back to our website. In our case, the first iteration of the homepage that was proposed was burning through the process: we were prototyping before we had even understood what the actual problem was.
Why did we want to overhaul the homepage?
That was the first question that we didn’t really take time to ask ourselves.
Was it because we didn’t like it, or because it was old and we wanted something new? Or was it because it didn’t fit our needs and growth?
We settled on the third question: the problem with the former homepage is that it reflected a very nascent ProleWiki, one that barely had any content to promote and as such made an index page that mostly talked about ourselves and what we hoped to become, over what we had become.
But we design for people, and we shouldn’t design for our own ego. Along with our growth in terms of content, we also grew in terms of visits: from 0 visits (again, we all start from scratch!) to an average of 1000 per day, every day. We take a user-centric approach, which is one of many approaches, and thus wanted to design a new homepage that would be useful to our visitors.
Understanding our audience
Basically, if there’s no problem, then there’s no reason to design a solution. Design answers the problem-solution dialectic (two things that are diametrically opposed but cannot exist without the other also existing). There is no problem without a solution, and there is no solution without a problem: hence “I just don’t like the old homepage anymore” isn’t really a problem, and requires no solution. Once we create a solution, then we solve the dialectic: the problem doesn’t exist anymore, but new problems arise and create their own contradictions.
What was a problem, so to speak, was that we had accrued over time several different audiences; such is the nature of a wiki. From previous polls and feedback we received (which provides data and information rooted in the real world), as well as looking at our own analytics, we came to identify four audiences that visit our website. We gave each of them a cool name too:
Linkers: they visit ProleWiki to quickly grab a link to a page and post it in a discussion or comment section they are in, to serve as a reference instead of writing an entire comment.
Sourcers: they use ProleWiki to find sources and read them directly, which also helps them discover new sources of information such as writers, media organizations, etc.
General audience: they visit ProleWiki because a topic is trending and they might google it, or a comment with a ProleWiki link is going viral; generally, they don’t come back and they only look at one specific page.
Prospective editors: they open ProleWiki specifically to request an editor account; they don’t necessarily read it but want to get involved.
This is also called a persona, the profile of an average customer/client/visitor that serves as a tracking point throughout the design process. There is no judgment or bias in the outlining of our audiences; it is important to know them objectively so that our later solutions can always stay rooted in the real world and answer a real need. For example, if you were us you might not like the general audience, who only reads one page and then leaves without ever engaging with the rest of the website. But if we removed this audience from our list because we didn’t like them, then we would be attempting to change reality: except we cannot change this fact, we would only be masking it. Knowing our audience fully is the only way we can start designing a solution.
At this first stage, we’re not even looking at any problems yet. You might start to think of some solutions though, and this is perfectly natural. We see the sourcers and think: well, how can we help them find those sources then? This is unavoidable, because we’ve layed down the situation so objectively and simply that we can’t help but start thinking of potential solutions: design is that easy.
Finding out our audiences, however, was not so easy. What you see here is the result of a few days of thinking, discussing and looking at the data until we could synthesize all of it into four coherent groups. But it’s based on real facts: we don’t just “think” we might have this or that audience, we go ask them. We ask neutral, non-leading questions and let people answer before asking follow-up questions. We don’t tell them what the questions are for, we let them answer as they like and write it all down. Then, we put all this data together and start figuring out similarities.
One question I might ask for example is simply “what is the first section of this page your eyes looked at?” They can’t tell what their answer will be used for and we are thus more likely to get an actual answer.
In the second phase of the understanding step, we start looking at the users’ pain points. These are things that make their tasks harder and that they would like to be easier. In some cases, it might even make them leave the website! Users on the internet have very low tolerance for pain points, and after the third one (or even the second one), they leave. Again, you can ask your audience questions about this. In this case, we had four years of data to pull from and mostly knew what these four audiences thought.
Linkers, for example, thought that searching on the wiki could be difficult. We knew this because some people had asked before about the search bar as they had difficulty finding it: we didn’t need to ask them directly as they told us in the past. Sourcers were interested, from their persona, in discovering new content creators and other authors, newspapers etc that they could start following. But our old homepage did not offer any of this content. Prospective editors, which we also knew from past feedback, sometimes had issues finding the registration page.
To understand prospective editors better, we simply asked the people we had most available: our own editors, who are all mostly on the discord server. I asked: What made you want to join ProleWiki in the first place? Perhaps unsurprisingly, most said they were looking for a community to join because of loneliness. A lower portion answered that they wanted to participate in the movement barring parties they could join around their areas of living. This was all information we could use in different ways to incentivize prospective editors to join us, and not just on the new homepage.
In any case, the audiences ran into these problems because our homepage, which they visited first during their journey (the time they spend on our website from start to finish and the actions they undertake) did not offer any solutions. On a different page, they might have different problems.
The general audience was slightly different in that we knew they didn’t visit the homepage at all: we knew this from looking at the pages this group had visited in the past, and saw that they generally left the website after reading the page that was trending. However, this was still interesting information! Lack of engagement also provides feedback, just as much as abundant engagement does. Since we knew that they didn’t care to visit the homepage, we figured that there was no need to devote a space to them specifically: note how on our first homepage, we had an entire paragraph explaining what ProleWiki was and what you could do with it. This was not needed because if we wanted to court the general audience it wouldn’t happen through the homepage, leaving us more space for the audiences that actually use the homepage and transit through it on their journey.
At this point, we are still only going through the problems by looking at our current (which is now the outdated) homepage and comparing with our audiences. We can rely on data for this, but we can also put ourselves in the place of a persona and visit the website like them: sometimes, the understanding step of the design process is also called empathizing, because you need to get in the shoes of your audience to know how to design for them.
We only start thinking of solutions in the ideating phase; in the defining step, we figure out how to answer the problems and pain points.
Defining the issues
The problems we needed to solve, based on all that we had built in the last phase (first rationalizing our audiences and defining them, then finding out their problems) was that:
We needed a prominent search bar for the linkers,
We needed discovery of other projects, figures and spaces for the sourcers,
We needed a prominent “join us” link for the prospective editors,
We didn’t need an introduction paragraph for the general audience — actually, we originally wrote this one as something we needed in our early design documents, and I decided to keep it in this essay to show that sometimes, you do go back to the drawing board, and sometimes (many times in fact!) your assumptions later turn out to be wrong, and that’s completely normal.
This would be the starting point for a new homepage, and you can see all of these elements in the screenshot at the beginning of this essay, meaning that they all made it in!
Everything that we didn’t specifically outline at this point was not necessarily irrelevant, it’s just that we didn’t necessarily think of it at the time or that it was strictly necessary to solve our problems, e.g. the featured essay and book recommendation.
Ideating our solution
With all this information in hand, we had pretty much all we needed to start ideating a solution, i.e. a new homepage.
This didn’t happen by opening the website, creating a page, and typing code.
We were still far away from touching the keyboard. The first thing I did was actually take a piece of paper and start drawing a mockup with a pen. I’m a proponent of “start with the least effort” method in design: go from what takes the least effort to the most. Thinking about a solution takes the least effort. Then, writing down keywords (such as heading logo, search bar, book recommandation, join us button, history calendar, featured page, featured essay — these are all the elements that are on the new homepage!) takes the least effort after thinking. Finally, drawing a crude mockup takes the least effort after writing down keywords. What takes the most effort? Actually coding the page properly (at least for me). As such, we would be leaving the actual coding for the very end of the process.
I can’t find the actual mockup right now, but I can show you a quick rendition of it that I made in Paint just now:
This is 90% close to the actual mockup I made. It doesn’t need to be pretty; borders don’t need to be aligned, text doesn’t need to be centered or actually written, and it doesn’t need to have color, shadows, font styling, etc.
What it needs to do is give us an idea of what the final page will look like so that we can code it to these specifications, making it look as close as possible to the spirit of the mockup. Since a mockup is somewhat low-effort (I estimate I spent maybe a maximum of three hours on the full mockup that I drew), we can also easily redraw it.
The mockup provides the first visual representation of all our work so far; it helps figure out if we were right in our assessment, if the solutions work or not. You have to understand — I didn’t really spell it out yet — that this mockup was only possible because we had done all the previous necessary work of figuring out what our old homepage lacked, what our visitors needed on a homepage, and how we could provide them with that. To go straight into drawing a mockup without doing this prerequisite work would be like going on a trampoline without learning to jump!
Ideas don’t come out of nowhere, and for the header to this mockup, we took heavy inspiration from the Star Citizen wiki, who also provide the theme we use on ProleWiki. We took their homepage’s header because it was just so perfect that we couldn’t improve on it in any way (and was likely, for them as well, the result of a long design process — see for example their inclusion of a search bar at the top). The extent to which one steals versus takes inspiration from is a fine one, but I think one of our strengths as human beings is to be able to build on what others have made before us, in a cycle of inspiration-creation-inspiration. While we based our header on their rendition, everything below that is our own creation fit to our specific needs.
The validation of the mockup by my co-admin who was working with me on this project meant that we had finished with the ideating phase. Sometimes, ideating is much more involved: your initial problem might be much more abstract. In our case, we knew we wanted a new homepage and only looked for a homepage; we knew exactly the scope of our process. But sometimes, you might start with something much less concrete, e.g. “How do I get food on a desert island?” and there you might have coconut trees, small wildlife, berry bushes and fish. How do you decide what to focus on? Do you spend time trying to get the coconuts down, building a trap for the wildlife, figure out how to know if the berries are poisonous, or try your hand at fishing? The problem can be further compounded by the fact that you are hungry and every fruitless attempt will tire you out even more, and you need to keep some energy to start a fire before sun sets! (As survival experts will tell you, you should have taken care of finding shelter before setting out to find food.)
Thus the design process helps us not only prioritize what matters, but also assign our resources correctly (where they will be most efficient while minimizing waste).
Part of the step of ideating is to know what your prototype will look like before you implement it. Before you figure out a process to know if the berries are poisonous, you have to know if you’re going to try for the coconuts or stick to the bushes. To decide means to rely on data once again: the amount of time you have left before sunset, the amount of effort you estimate each solution might take, etc.
Prototyping a homepage
Coding the structure of the homepage itself was not very difficult with flexboxes in CSS. Fun fact: most of our new homepage relies solely on HTML and CSS (as well as some MediaWiki-specific code). I don’t hate Javascript, but more and more people block it nowadays and so we can’t rely on it to display important information. It also runs with a noticeable lag on MediaWiki, not slowing down the page but displaying long after the page has loaded everything else. The only use of Javascript on the page is to display editor testimonials on the “join us” box when there is a lot of blank space and to open the search function when one clicks on the search bar in the header, which was required because of the way search is implemented in this theme.
The structure is basically the skeleton, or the template that we fill in. It’s the header (our logo and name), the search box, the “pillbox” (the name we gave to the 12 rectangles with an image and text at the top) and then the various boxes such as join us, read next, featured essay, etc.
This was easy enough to implement [the process of turning the idea into a prototype], but we ran into a problem of our own afterwards: how would we select for, and display a random book from our library? Sure, we knew what we wanted to display (book name, cover, author, etc. and a link to “see all books” which takes users to the library), but how do you randomly display a book that exists in the library? There needs to be a mechanism that selects a book at a certain interval and displays it in this box.
Thankfully, I was able to make use of my previous experience with DPL which we used when making the new Library homepage as well as the new Essays homepage. DPL is a MediaWiki extension that gives it a small amount of semantics; semantics are basically a way to turn data into information for the computer.
If I type, for example “capital volume 1 karl marx 1867 economics” you might be able to interpret this as a book titled Capital Volume I, written by Karl Marx, published in 1867, and in the category of Economics. Your brain is able to do this intuitively — give meaning to strings of data — because it is able to pull from pattern-recognition and things you know already; you probably already know Karl Marx, even if only in name, and that one of his most famous book is Capital. You can then infer with almost 100% accuracy that 1867 must refer to a publication date, and economics must refer to a category or topic.
A computer can’t do this by itself. It needs to be told all of this information. It needs to be told title=Capital Volume I, author=Karl Marx, publication date=1867, topic=Economics.
But this information, barring the use of AI (and AI isn’t even that great yet at doing this), needs to be hand-fed to the computer. For every book in your list, you need to specify these parameters so that the computer has a standard, unique key to identify each field. “Publication date” will always and only refer to the date a given book was published, and nothing else. Then, we can start displaying that information dynamically. We can tell the computer to display text that reads “$title was published in $publication_date and written by $author”.
This is semantics; it gives meaning to strings of text so that a machine doesn’t interpret the data as solely a string of text. Semantics can go very far, but we’ve thankfully managed so far without having to go into them very deeply.
DPL gives us some semantics capabilities, and so far I have to admit it’s never failed us, and we use it heavily. To display a random book in the “Read next” box, we need two things regardless of the solution we intend to use:
We need the book to be in the Library namespace, which is basically a super-category,
and we need the book to have semantic information available.
We achieve condition 1 by uploading all our books in the Library namespace; I won’t get into namespaces as they are a MediaWiki specific thing, but they basically allow us and the computer to understand “Library:Capital Volume I is for the book itself that Marx wrote whereas the page Capital Volume I is to talk about the book. Category:Capital Volume I is a category page to regroup pages related to the book”, etc.
We then achieve condition 2 by including a template on every book, which I won’t get into either. This template gives each book this semantic information: the title, the author, the publication date, and whatever else we want. Editors need to remember and fill this information in manually each time they upload a book, and sometimes they might forget, but it works perfectly well otherwise.
With these two conditions met, DPL is able to create a Dynamic Page List of pages in the Library namespace. It looks for a page that is in Library: and then finds the template and pulls information such as author, title, publication date from it to display it on the new homepage.
And it’s as simple as that!
… Theoretically, at least. The code to achieve this is very straightforward, but the documentation for DPL is not very user-friendly and it’s hard to get into it. It looks as simple as this overall:
We do have some extra lines because the documentation doesn’t explain how to use “notcategory” (meaning we don’t want to display a page that is in any of these categories). Without those extra lines, the code needs only 11 lines. This is made possible because DPL is a very powerful plugin that can be used for many things, one of which is pulling a random page from a selection that changes every day!
What we tell it to do is select all pages in the Library namespace, which it puts into a temporary, invisible list that only it has access to. Then, we tell DPL to display 1 random page from this list — technically however, DPL creates a list with up to 500 pages in it. For purposes of server load, it doesn’t look beyond the first 500. To avoid that and give each of our 1000 books a chance to display, we change the randomness seed every day (the seed is literally today’s date, meaning that every day, a new list of 500 pages is created).
… I hope you’re still with us! This was very technical but I felt it was important to take the time and explain. I’m sure that in your line of work, you’ve had non-professionals tell you before “I need you to do this”, with no explanation on how they expect you to achieve this. Often I’ve had colleagues ask me to “update the homepage” on their websites… but update with what? You need content to replace content. It’s not sufficient to say “this needs to change”, or “this needs to happen”: you are responsible, as the person who brought up the idea, to figure out how this will happen exactly. This is what turns you from the “idea guy” to a designer.
As the designer to this new homepage, it would have been insufficient for me to propose an idea (displaying a random book) while leaving it to others to figure out exactly how to make that happen; I would have only done one half of the job.
In any case, with the random book implemented correctly (it behaved the way it was expected to: pulling a random book and its information, with a link to its page), we somewhat easily implement the other random pages: the featured essay and the featured article. They also rely on DPL, but work a little bit differently.
Reversing the pillbox
As for the pillbox, which came from the wiki that provided our theme, it was a feature that we wanted to have on ProleWiki as well ever since we discovered the Citizen theme. Just looking at theirs in isolation helps figure some things out design-wise; design thinking can help reverse-engineer things!
Or maybe rather than reverse-engineering, I would call it redoing their design process. We don’t do things for no reason: even if the reason is very light, it’s there. There’s a reason the designers of the Star Citizen wiki wanted to have these 12 “pills”, and there’s a reason they 1- added them to their homepage 2- in this location 3- with these visuals.
(The reason we call them pills, by the way, is partly because they look like pills, but also because each different structural element needs to have a specific name so that we can refer to them precisely internally. We call these pills so that I can quickly say to my co-designer “there’s a bug with the pills”, and he’ll know exactly where to look.)
This reversing process is very important in design and happens all the time. It’s what makes us better designers, and makes better products. If we said “well we can’t have the pillbox because they already use it”, we might be doing a disservice to our own visitors who could benefit from them.
In this case, we figured the pills were designed as such:
A solution to provide quick access to the most visited or important pages,
Looking organized in a grid fashion to convey that they relate to the same element,
With a generally darkish picture with one highlighted element set to the right side, leaving the left side of the picture for the text.
Which were all decisions that applied to our needs as well. We ported the pillbox over to our website (originally coding our own solution, but it came with several issues that they likely ran into themselves and ultimately fixed with their version), and linked them to both pages we knew visitors wanted to find, and pages we wanted to put forward as we consider them qualitative.
These are often two different pages! We know which pages are the most popular from looking at our own analytics. We can pull data for the whole year of 2024, for example, and look at the top 10 visited content pages. Then, we can look how people found these pages: if they had to search for them with the search function, or if they found them on Google, or if they were linked that page on social media, etc.
The pages we want to put forward are pages like our marxism portal, which we built some time ago to serve as a 101 repository, but doesn’t see much traffic — it’s a problem with wikis and how discoverability works on them. Unless you search for a specific page, you will very likely never come across it. Other pills link to parent category pages such as the category for Countries, Parties, etc, helping to redirect people to more specific pages.
This is of course potentially temporary and the links might change (though ideally as little as possible so as to reduce confusion); the point of the pillbox is to get people to where they want to go as fast as possible so as to avoid pain points. If we find that some pills are never clicked, then that data indicates that we were wrong in our assessment that this page was something people wanted to quickly access and we can easily change it.
Adding redundancy
Pages such as the library and essays space don’t need to appear in the pillbox as they have their own dedicated boxes in the Read Next and Featured Essay sections. They are also accessible from a button in the sidebar on desktop (unfortunately, there isn’t enough space on mobile to add them there), but we found from feedback that people weren’t really sure what these buttons were for and didn’t use them. Hence we bring in redundancy: the act of making an element accessible from more place than one. You use this all the time on computers without noticing it; for example, this error box on Windows:
Can be closed from both the Close button and the red X in the top right corner. Both buttons do the exact same thing when clicked, but both exist side-by-side because that’s how Windows message boxes are made: some require you to say Yes or No, and some can’t be closed until you take an action because they are important. It doesn’t make sense for this box, which is a warning message that an operation can’t be carried out, to prevent you from closing it with the red X when you can close it with the Close button. The buttons are redundant, but actually help users navigate an environment that might be unfamiliar to them. It also reinforces the association between the red X button and closing a window.
The same line of thinking applies to our redundancy on the wiki; previously, we added this quick links menu to the former homepage:
This was a very quick and hacky fix because we knew that we were going to redesign the homepage from scratch, but we also realized that people had trouble finding the library and essays, or rather, many visitors were not aware they existed! We knew this from the same sources of data as always: our own private analytics and forms we sometimes send out.
On the new homepage, a book and an essay are directly integrated into it. A link to see all books or read the full essay is integrated in their respective sections. Furthermore, we use the two icons you see in the screenshot above (the semi-dark open book and the newspaper icon) solely for the library and essays space respectively, so as to reinforce the connection between these icons and their meaning. In the new homepage, we use them in the red header for each box.
We expect that this new feature will help people discover new books and essays and drive more traffic to these pages, but of course we will only know for sure with enough hindsight after we’ve collected the data for a while!
Bug resolution
After that, everything else fell into place and we made quick progress. This is usual; the bulk of the work is actually easy to get through, and what takes some effort to go through are the “stragglers”, the small glitches or forgotten problems you need to fine-tune. For example, testing the page on mobile (and you should always test on mobile ASAP because more than 60% of visits nowadays happen on mobile!), we found that the search bar required two taps to work. This was unexpected behavior, which is a more precise term than glitch: unexpected behavior shouldn’t happen, it’s not what we want the feature to do or how we wanted it to work: we wanted it to require only one tap to open. One tap is expected behavior, two taps becomes unexpected behavior (or even zero taps!)
Bug resolution doesn’t need to be fancy. As we worked on the page, we simply kept a list of tasks and glitches that would need to be taken care of eventually. We opted to focus on them as time permitted or at the end of it, when all the functionalities were working. Some of them we are keeping for version 2, or v2, which is post-release. Essentially in the development cycle of the prototype, we have v0 which is the start of development. V1 is release — when the new homepage goes live, replacing the old one, and is publicly accessible and put out there for the world to see. V2 is anything post-release, that we work on while the page is live.
It’s important to be able to prioritize like this. In our case, we’re not too pressed for time; it’s not like we have to deliver this page to a client with a deadline, or that people are picking up pitchforks because they really want to see it. But we are excited to put it live and see what people think of it (early impressions from testers are very positive!), and of course we don’t want this project to last longer than it has to. We want to finish it as soon as possible before abandonment sets in and we kinda forget about it and move on — it’s a real problem in volunteer-based projects.
Once you release your prototype, or even as you are coding it, you need to test it in real conditions.
Testing your prototype
This is make or break, and where all your efforts pay off. Testing happens in real conditions: you have to actually get people (who were not involved in the project whatsoever) to test the prototype you’ve designed and give you feedback. This can be done in person (stand near them and take notes but don’t talk to them), or online (send them a link and ask for their thoughts afterwards).
I like to tell as little as possible to my audience of testers. I might drop the link in a discord server or similar, and just say “what do you think of this?” without giving more information. I don’t want them to know I made it, or that I’m specifically looking for feedback, so that they give me something raw, without trying to mask any of it.
I seek feedback purposely several times during the prototyping process, once there’s actually something to show for it. For example, with this homepage, I only started showing it around after the features were implemented: the problem when showing your design to someone who was not involved (even if they’re a designer!) is that they don’t have access to your work documents, your design process, all the mockups and steps you went through. They only see the final result, so they don’t know what you have planned, what’s expected behavior or unexpected, etc. This is why I want to wow people when I show them my prototypes, so that they have something interesting to look it, promoting more feedback, and that they don’t tell me something I already know, e.g. “this doesn’t display properly” when I already know it does. It’s not so much to save my ego, but there’s a possibility that I’ve experienced where they start fixating on one glitch that caught their eye, coloring their overall impression of the design.
I collect their first impressions by letting the testers speak. I don’t ask any questions or tell them anything, I just give them the link and ask them “what do you think?” or “check this out”. If you submit a design to your tester and tell them “the color might change, also this doesn’t display properly but it’ll be fixed”, it will prime them to have the idea that the color is a bad choice or that there is a glitch on an element that they have to look for, when they might not have even noticed it if you hadn’t told them!
It’s only afterwards that I start asking follow-up questions. It’s important to be as neutral and non-leading as possible in those questions. For example instead of asking “what do you not like?”, I ask “what do you think could be improved?” “Not liking” has the connotation of being bad or impolite, which most people try to avoid being. “Improvement” has the connotation of being positive, of seeking progress. You can even be very specific and ask very pointed questions:
What were your first impressions?
Can you walk me through your thought process as you use this?
What part stands out the most, and why?
Was there anything that you expected to happen that didn’t?
Again, we can only work with real data, and real data is objective. If I start looking for a subjective impression, I am not collecting real data.
I might also try different prototypes with slight differences. For the new homepage, we tried changing the color of the headers from red to black. I sent the modified page to people for a test without telling them anything about what I was testing for, just to see if they brought up the color by themselves. If they don’t, then I might ask them directly: “how do you feel about the color of the headers?”
It turned out people generally didn’t like the proposed color, and so we reverted to red.
Testing is an integral part of the design process and can’t be skipped over. If your tests don’t match up with your expectations, then it might be necessary to go back to the ideating phase. More often, you only need to reiterate the prototype — bring some changes to it and then test again.
This is when the entire process becomes meaningful and why it follows this precise order of steps (though as I’ve said, you might jump back and forth between steps naturally). You can only gather feedback once you have something to show for it, and it’s only useful to show something that you have spent time thinking about. I could absolutely make a mockup for a random homepage based on nothing but vibes, and ask for feedback on it, but what would it tell me? Anything that people liked in it would be mostly based on luck, and anything that people do not like in it would require me to understand their problem more deeply so that I can define it and ideate a new mockup on it. I would be back to square one very quickly!
Once your prototype is finalized and ready to release as a full-fledged product (in our case, formally publishing the new homepage and replacing the old one), you are not done iterating! It’s a potentially never-ending process. However, generally, once we release the “product” we stop looking for feedback actively, and let it passively come in when someone contacts us. We look at more passive sources of data; for example, we set up tracking links on the “pillbox” (this data doesn’t leave the website and is only accessible to administrators) so that we can know when someone clicks on it. This way, we will be able to tell after a few months if they prove to be popular or not. This is passive data because we collect it automatically through normal usage of the website and with enough time. If the “pills” prove to be unpopular, then we might start the process again: understand why people don’t use them, then prototype a replacement (or scrap them entirely).
Self-feedback
External feedback is only one part of the equation. You can and should also do self-feedback, or internal feedback, also called a debriefing or self-criticism (criticism not as in criticize but critique). As the designer, you can also answer for yourself: what works, what doesn’t? You can furthermore analyze your process, and learn from your shortcomings or things you felt didn’t go well, that you struggled with or went the wrong way. I highly encourage this sort of self-criticism. The point is not to beat yourself up over your failures, but to continuously improve. You will not remember the failures years from now; you will remember where you are at and how much you’ve had to grow to achieve that.
Emergent design
I call emergent design all the things that came up during the process and were integrated that weren’t part of any preliminary step. For example, I mentioned that we removed the introduction paragraph because ultimately, it was only interesting to the general audience, but the general audience did not look at the homepage. As we did this, we realized internally that it also signaled something else: it signaled that we had entered a new era in our growth, one where we didn’t need to tell each and every new visitor who we are and what we do, instead letting the content speak for itself: long gone are the days when we had barely 10 pages to read; we now host more than 3000 pages, and 1000 books, and receive more and more visits every day. We don’t need to introduce ourselves and convince people to read us; our content does that for itself. This was only made possible with the help of our many editors, showcasing that ProleWiki is a collective project requiring collective effort for a common goal.
Use design!
When I wrote my previous (and first) design article here, I asked for feedback: Do you want to read more about design? To my surprise, everyone that answered said yes.
I think that design theory is useful to everyone, and I’ve yet to find a situation where it couldn’t help me. Most of all, I find it to be a skill that anyone can learn; it’s more of a soft skill that gets acquired and perfected with experience rather than a hard skill that requires rigorous study. We’ve seen you could even use the design process to help find food efficiently on a desert island.
But this also means you need to use the skill to acquire it! Obviously, I don’t use design thinking for literally everything I do, but I could. So why not try that as an exercise? You can use this process on your social media posts, when planning an event, before a big purchase (in this case you are the audience!), at work, etc. Your process doesn’t even have to be thorough or expansive, it just has to be. Then slowly, piece by piece, you’ll start growing more comfortable with the tool and improving your answers in each step.