Case Study: Red Ant
Wikipatterns – Table of Contents
A Conversation with Ben Still, Managing Director
Sydney, NSW, Australia
Red Ant is a web design and development firm in Sydney Australia that designs and builds web sites, games and online advertising, as well as the interactive elements such as games and menus. The firm has won awards for its work from the Australian Interactive Media Industry Association, Australian Graphic Design Association and several London International Advertising Awards.
Why did you choose a wiki?
We tried a number of different approaches, and looking back they were all based on a central editing model. A wiki made sense because we wanted everyone to be able to contribute and participate. It is also closer to the way that we like to work with our customers. By allowing everyone to be able to add and reshape content, more people became involved. We moved from one person slaving away creating pages and the rest of us having to wait for them, to a situation where one person gets the ball rolling, and then other people can join in to complete the task.
Say, for instance, we’ve created a design and need to show it to our client. First, a designer makes a page, attaches an image, and they’re done with their part. But then I might look at it and realize that it needs a bit more explanation, or a link to a wireframe diagram to give context. One of our developers might have also mocked up how a menu works, and so they stick in a link to that. Our client might email the link around, and then add some comments on the page. This kind of collaborative workflow is one of our strengths, and it is really important for us to be able to add these various types of content easily.
I’ve come to realize that there is no “right” way to handle this communication process, and it changes radically from project to project. I would imagine some industries might suit a more formulaic approach, but we didn’t have much luck – things just change too quickly and people ended up working around it rather than with it. A wiki approach has been great, since it’s so flexible and adaptable.
What type of wiki are you using?
We use a enterprise wiki solution that we host on our internal servers.
How are you using the wiki?
The main way that we use it is to communicate clearly to our clients. We use it throughout the entirety of the design process.
The first stage is where we can communicate ideas and establish scope of the project. This has included the unexpected benefit of being able to document meeting notes so that everybody is clear on meeting outcomes and expectations – something I’m sure everyone that has ever had any sort of meeting can attest to as a potential problem!
From there, we typically use the wiki to put designs or prototypes in a space where the client is able to see them and respond quickly and easily. This transparency in the process allows us to quickly and proactively respond to requests and changes. Another benefit of the wiki is that it can be easier to explain potential challenges or pitfalls through a wiki than by email or phone. This can be especially true for design problems, where being able to easily markup a solution, or include a screenshot can communicate an idea much more clearly than any other potential method.
Towards the end of the design process, we put the links to the staging version of the site into the wiki. While the work itself is offsite, we still find it useful to have one place to collect feedback, track progress, as well as keep any feature requests for future work.
Another of our strengths is in analysis of data: we’ve also had some great success in using the wiki to present feedback and stats analysis using live data. For example, we’ve used this to graph results of a web promotion as it’s happening, which allows the client to understand when they might plan marketing around that promotion. Afterwards, it helps us to be able to give an analysis of the project, which is tied to all the prior information, very helpful to anyone who may not have been involved in the nitty-gritty but wants an at-a-glance summary.
Sometimes if we’ve get a tight time line on a project, we’ll also use the wiki to create a visual checklist of tasks until launch. This is especially true when there is quite a few different parties involved – many hands make light work, as long as all those hands know what one another is doing! This has been a good way to coordinate effort, as well as show the client that progress is being made. Alternately, we’ll pull in a list of issues from Jira, our issue tracker. We’ve found that people are much more likely to view and understand a list of tasks if they’re pulled in as a feed to a wiki page, rather than having to log in separately to the issue tracker.
We use our wiki to build up information, but another thing we’ve found incredibly effective is to build filtered views of information. The main space structure can be a bit daunting, especially if its a big one for a very active project. We make a “WIP” page, which pulls in summaries of key projects. They’re ordered by date, and we tag them with appropriate status and category information. From this one summary page, clients get a great snapshot of current progress and can then dive in deeper for more detail. These pages require a little love to keep them useful (updating summaries, reorganizing tags, etc), but these custom WIP pages have become the most used part of our wiki spaces.
Which wikipatterns are in use on your wiki?
In terms of maintenance, our team maintains the wiki and are the most steady users of it, which makes us the combination *Maintainer*/*WikiGnome*/*WikiZenMaster*!
While we don’t want to limit the freedom of our clients to use the Wiki in imaginative ways, it’s a reality that for us most clients will use it for fairly defined purposes. Generally, this falls into a couple of categories: uploading assets, providing feedback, and sometimes providing briefs or additional information.
To this effect, we’ve used the wiki’s inbuilt templating system to set up a number of templates, or *Scaffolds*, which make it easy for us to quickly set up new areas for clients. Our hierarchy is set up in terms of ‘Clients’ and then ‘Projects’, this allows us to provide security – so that clients are restricted to their own space, as well as provide each client with a snapshot glance at all the projects that might be taking place for them. This of course, all lends itself well to the *OneWikiSpacePerGroup* pattern.
It also provides an easy *StartingPoint* for the client: within the template, we provide some brief instructions, as well as an *Invitation* shortly afterwards. We find that it usually doesn’t take them too long to get the hang of things.
We find that both an *Agenda* and an *Automatic Index* are fairly crucial to the way that we’re working. Knowing that everything is in the wiki means that there is a degree of transparency between us and the client, they know what we’re working on, and what stage we’re at. I guess it’s similar to a *LunchMenu* as well, since we will also email to notify less frequent users of changes, or if we’ve reached a significant point in a project that requires feedback, and in the email we will point them at the wiki, and invite them to comment or contribute.
*90-9-1* probably isn’t quite the right ratio for us, but there certainly is an element where we’ll have ‘lurkers’, who keep themselves abreast of all the changes in the wiki even though they never take the plunge. This isn’t something that we’ll complain too much about though – as long as things are getting communicated, one way or another!
What changes have you seen as a result of using a wiki?
The main difference is that communication is stronger across the board: within our own team, with our partners in the US (we’re in Australia), and of course with external clients. While we still use the tools like email, face-to-face meetings, bringing wiki into the equation has meant expectations are clearer, feedback is quicker and more effective, and as a result, projects are better managed.
For clients, this means that they are better informed. Rather than having to ask us directly for information, they’re able to do a bit of research for themselves within the wiki. This means that when it does come to communication, it’s a more informed discussion on all sides.
It might be obvious, but the collaborative nature of a wiki also means that we can spend less time trying to chase various elements, such as content, assets or feedback, and that process of client contribution is intuitive, even fun! This results in happier clients, and means that we can get on with doing our job of building better websites.
Internally, using a wiki has meant that information gets to the people who need it more easily. With email, you can get the problem that the necessary information could bottleneck around one person, especially if they were busy, or if they happened to be away. This doesn’t happen with a wiki – even the process of regularly reviewing and updating the information in the wiki raises the general level of awareness.
It also empowers each member of the team, giving them more transparency as well as more responsibility for what they have to do. In concrete terms, this means that our designers can get updates to clients in one step, while managers can monitor the changes and communicate more easily with clients.
Also, using a wiki has been the best way that we’ve found to keep those scraps of information, that just don’t fit anywhere else. Examples range from logins and passwords to websites like a stock photo site, documenting our processes, and even keeping a collaborative ‘list of contacts’ which is easily accessible by everyone in-house. We’ve tried numerous things for these bits of information, and a wiki has been the best solution by far.
Lastly, one of the best things about a wiki is that it maintains a transparency to our clients in terms of the work that we’re doing. Before we maintained a wiki, there wasn’t as much communication to the client, and no way of them knowing what we’re doing, short of directly contacting us. A wiki means that they’re kept abreast of any developments on their project, making us look as productive as can be. In the end, our wiki helps us to work better, and it helps our work to look better too.