How to redesign an internal wiki (that people actually use)

It might sound odd to get a designer to clean up somebody else’s thoughts, but we’re more suited for the task than you might think. There’s just so much that a new process or a new shiny tool can do when the source ideas are not well defined. Sometimes you need a good spring cleaning to rearrange the furniture and polish up the language — and that’s when Information Architecture’s principles can help. Whether you want to work on a wiki, redesign an internal process, or sort out someone else’s navigation, here are five steps to get you started.

Before you start — Find your allies

You’ll need a partner in crime for this job. Information architecture (IA) doesn’t work without help from a team member or a push from their PM or manager. You can create the most user friendly, simple and elegant solution ever, and it’ll still go back to chaos if no one buys in. So before you start, find someone else in the team who cares about how people are consuming information. I like to say wikis are like language or culture: if no one uses it, it dies.

The second person wanted is a copywriter. I know that’s not common in most companies, so keep in mind that marketing folks are usually pretty good at this. If no one can partner up or give you guidance, you’ll have to rewrite it all yourself. Yeah, I know. I can hear the complaints from here already. Listen, writing is hard, but there are some shortcuts to make it easier.

Step 1 — Define your requirements

Knowing the documentation is a “mess” or “confusing” is not enough. You’ll need to understand what’s causing friction and translate it into key metrics:

• Someone could have already gathered the problems for you. Find the local team’s experts and ask what’s on their minds.
• Shadow the people who consume that content. The beauty of working with internal teams is that your user is right there and eager to chat! Just say hi, and throw something at their calendar.
• If this is a new wiki, steal from your ‘competitors’. Note here, that ‘competitors’ could also be another team on your own company with a tidy wiki. Absorb what they’re doing well and take notes of what you want to avoid.

I like to condense all these notes into a design brief. I’ll define the project’s goals, background, supporting evidence, key pain points and what I am aiming to improve. Bonus brownie points if I can measure the ROI (return of investment).

Step 2 — Understand your content deeply

This is the most intimidating step for me. I see design as finding the path of least resistance: a solution should be elegant and simple. So, I can’t simplify something that I don’t understand.

Here are some shortcuts to help you inhale years of processes or thousands of pages at once.

• Experts are life saviours. Ask them to explain the process or docs to you. Chances are they’ll know some nuances that aren’t written down. A good meeting agenda idea is to open up the file tree of what you’re trying to redesign and ask them to talk you through it.
• Read the documentation. Try the service. Do the task. Keep notes. There’s nothing quite like trying something new by yourself.
• Future proof it. Ask what’s coming next, if they intend to change it, and which areas may be added next year. None of it may happen, but it’s better safe than sorry.
• Keep notes of your questions and which words or concepts are hard for you to understand. Later, you can create an FAQ or Glossary that is very useful for other newbies. You’re only a newbie once. Treasure it.

Even if you’re not an expert in law, insurance, operations, or code, chances are you work in the same industry as the people who asked you for help, and you have that minimum shared context. You also could resemble their end-users, someone a bit removed from this process on their day-to-day, so being a newbie can be a real advantage.

Step 3 — Design

Chances are you are now bursting with ideas. Once the problem is laid out in front of you, the new IA can reveal itself like magic. After all, good design is simple, right?

Well, in case the light doesn’t shine, here are some design principles to get you unstuck:

• Task vs Topic-based organisation. I personally find task-based navigation a more approachable design. Chances are your user doesn’t know what your different topics mean and how are they different from each other, but everyone has a task to complete.

• Miller’s law — It states that the number of objects an average person can hold in working memory is about seven, plus or minus two. I know it was debunked to a point, but it’s still a great rule of thumb. People can process just so much information, so avoid giving them analysis paralysis.

• 80/20 rule — 20% of your pages are seen 80% of the time. That also means that there’s no shame in having a “Quick Links” section with some misfits thrown together. A handy group of favourites can be welcomed. Think of your browser’s taskbar.

• Make content skimmable and polish up the micro-copy. People don’t read. Or rather, people skim on the internet. That may mean you’ll need to rename a process or page so that it resonates better with the users’ natural language. Make sure to structure your content with bullet points, bold sections, descriptive links and buttons.

• Run a card sorting test. You can choose the content by either picking the most important topics of your wiki, or selecting the first two levels of the current navigation structure. If you have 30 or 40 users, you can run this test unassisted, but I recommend being present and asking additional questions if your pool is smaller.

At this point, you should have a new Information Architecture plan. I structure the plan as a table displaying the new content groups, with a brief definition of each group, and some examples of what should go in them (see image below). You could go the extra mile by creating another table and retrofitting all existing pages into your new structure.

Information Architecture plan

Step 4 — Test

You have the first draft! It can the winner, or maybe it needs some adjusting — only user testing can tell you. Bring your IA plan to these next meetings:

• Talk to your project owner and your copywriter. Pitch your new structure. Chances are you missed something, or there are tiny wrinkles you need to smooth. Walk them through your proposed structure, and it’s okay if you need to repeat step 3.
• Go back to your users and see if the new structure is working. Try to create a user testing script based on their past pain points, and ask them to execute the same task on the new structure. Also, you may need to recruit new users to cover all your existing use cases — I always try to have 2 or 3 of each.
• You can run a tree test. Design some questions around your key pain points. Do two tests, one with the old structure and another with the new one. This process will generate data that can help you calculate an ROI later.

Step 5 — Socialise it!

That’s it! Now it’s time to shout about it. Do a workshop with the team, present at an all-hands. Send that batch email. Set up those metrics and be ready for iterating. Make sure people know what happened and that the teams can maintain it.

Remember, your docs are just as good as people are willing to use them.

Good luck!

I’m a Product Designer at GoCardless.

If you feel that GoCardless appeals to you and that you would like to find out more about Life at GC you can find our posts on Instagram and LinkedIn.

Are you interested in joining GoCardless? See our jobs board here.