Design Documents - Victoria Donkersloot

Designing Collaboration

I like to work on software and technology related projects. But as a designer with a specific interest in design and not in programming I have chosen a position that always needs to be complemented. Interdisciplinary collaboration is an essential part of my job.

Within an interdisciplinary collaboration each person accounts for a specific part of the project. But these individual parts only become meaningful through good collaboration; all parts need to fit together to form one big whole. Understanding what makes and breaks good collaboration is thus very important for anyone who works within interdisciplinary teams.

Last year I collaborated with two other people, a fulltime programmer and a part-time project leader, on Apna Opus, a peer-to-peer file sharing application for communities. Although it all seemed to go well, towards the end of the project it became clear that our collaboration hadn't been optimal. For this presentation I have specifically examined the design of the documents we used to communicate with. I did this to understand what could be done differently in future collaborations. Before discussing these I will also briefly discuss other aspects that hampered our collaboration.

Firstly, we had no shared end goals. Without realizing it, we had different end goals. Apna Opus is the follow-up of Opus. Opus was an online platform that facilitated the sharing of ideas and media objects. We all wanted to improve Opus. The code had to be updated, it had to become more user-friendly, and it had to incorporate the needs of a specific community, the Cybermohalla practitioners. We all agreed on this. But along the way our own goals became more important. I wanted to transform the Opus interface into a more user-friendly, workable interface. Sylvan, the programmer, wanted to improve the code. Busy with these tasks we forgot that our work is inherently intertwined. To prevent this from happening it is important to keep communicating.

A second problem we had was that we had no centralized planning. We all had a certain idea of what had to be achieved within four months, but we never clearly stated this to each other. As a consequence individual parts were worked on longer and longer because no exact date for transferring the work to the next person was set. The lack of the centralized planning did not only slow the progress of the project as a whole down it also hampered the collaboration because it slowed down the exchange of the individual parts between the collaborators. So for future collaborations: make a planning!

Thirdly, we worked on different locations. Sylvan, the programmer, worked at the RnD-lab in Delhi. I worked at Sarai also in Dehli but an hour away from the RnD-lab. Monica, the project leader, worked at Sarai and abroad. Because of these different locations we didn't have many face-to-face meetings. Face-to-face meetings turned out to be an important way of keeping up to date with each other, of making sure that all work stays synchronized with each other. Face-to-face meetings were substituted by online communication. The documents we sent by mail thus unintentionally became very important for our collaboration.

I will now examine two documents that were created as a result of this situation and were meant as a means to help us communicate better. The first document is an Excel document. I initially created this document to organize my own thoughts. But once created I used it to share and discuss ideas with others. I wanted to make an inventory of all functionalities needed for the application. I wanted to know what tasks my future users wanted to be able to do. So after interviewing and observing my users I created a list with potential functionalities or tasks. Once the tasks were clear I could start designing the information architecture. Examples of these tasks, shown on the left part of the screen, are view image, view text and download media object. These general tasks are listed vertically. A general task like "view image" can be split up in more specific tasks like: Enter Apna Opus, in order to find a clicked or created photo, which is a photo that is not found in order to re-use it. These different categories were shown vertically.

Whether these tasks would be truly implemented depended on the technological feasibility, the conceptual implications and the users' practices. In order to discuss these aspects I included all task related questions in the Excel document. Questions meant for the programmer, technical questions, were color coded in green. Questions concerning basic concepts and decisions were assigned the color blue. Questions meant for the Cybermohalla practitioners, the potential users, are red.

So the document efficiently schematizes the tasks and questions, but is this design also suitable as a means for discussion? Does it allow responses to the questions that it asks? Does it enable feedback? In retrospect I would say no. So why is that?

For one the document was sent as an email attachment. The questions asked in the email are more or less the same as the questions asked in the attached excel document. Although the questions in the email are explained more by putting them in context, they are less organized; they are not color coded, they are not numbered, and they have no bullet points. By reproducing the questions from the Excel document, people are forced to read the same information twice and as a result of this the discussion becomes decentralized.

Secondly, presume the document was only sent as an attachment. Would this have made the document more suitable as a means for discussion? No it wouldn't. Presuming that you added a reply in your version of the document, replying to your reply would become very complicated for others to understand. Without a centralized document that everybody can edit, it would be very hard to maintain a discussion.

Thirdly, let's presume there would be only one centralized document. Would this have made the document more suitable as a means for discussion? No it wouldn't. Digitally adding answers to the Excel document is very impractical and labor intensive. The editing options differ per program and per platform. For example, in Excel it's possible to make the cell size dependent on the amount of text. This is, however, not possible in the open source version. So you have to manually enlarge your cells. In addition to that everybody is forced to learn to work with Excel.

Concluding this section I'd like to say that when the purpose of a document changes, the document design should change accordingly. For good feedback it is important to, create one central document that everybody can view and edit and it is a good idea to use an application that is relatively easy to edit.

In trying to find a solution to these communication challenges I also created a set of Wiki pages as a means for discussion. A Wiki is both centralized and relatively easy to edit. But is it suitable as a means for discussion? Yes and no. Changes on the wiki are not automatically reported, you have to send the others a notification by email but this did not always happen. Moreover we had no embedded or agreed protocol on when to reply, so you could get a reply to a question right away, or several days later. This obviously hampered our attempts to keep a discussion going. Another problem had to do with the fact that there was no embedded or agreed protocol on how to reply. A reply could incorporate a range of different elements, like the use of different colors, for instance in this email where the reply text is in black, and then in this reply the text is green. This doesn't include the different uses of names, included or not, the use of texts styles like bold, italics or underlined, or the use of special symbols.

http://apnaopus.var.cc/wiki/index.php/ Summary_of_the_subjects_discussed_during_the_Apnaopus_meeting_of_28_October

Without an agreement all of these things become very complicated; they make it very difficult to sift through texts for specific responses.

Concluding this section I'd like to say that it is not only important to have a central document, it is also important to notify others when you post something and also agree on protocols on how and when to reply.

At the end of this experience I have learned a lot by examining what hampered our collaboration. But the most significant lesson I learned is how incredibly important it is for team members to invest project time in communication and collaboration. Because without it all individual effort is lost. Thank you.

Question one [Matthew Fuller]: Are there any immediate questions for Victoria about Apna Opus or the working process? Okay, I think that one of the things that is interesting about this is, that it is a very good detailed examination of an actual work in practice designed to produce a piece of software to enable collaboration. So if you are theorizing about collaboration, if you are trying to understand, trying to make it occur, to actually abstract what collaboration is and then to rematerialize it as a piece of software is a very difficult task; it is a recursive task. I think one worth thinking about for designers and others.

Question two: Just a practical question, what would you recommend to use, with the knowledge that you have now. What online application would you use now to help you work on a collaboration?

Donkersloot: I'm not sure, I think...

Question two [follow up]: For example I could think of a blog or I could think of a forum.

Donkersloot: I found that it was very important in our case that we should not only have tried to communicate online but much more face to face, because, although we were all thinking we were working towards the same goal, and thinking we all wanted to make it more useable, in the end it became very clear that we all had a very different idea of useability. That was what hampered our collaboration, not so much the documents, I mean as well they hampered our communication, but it was more the way that we didn't talk, that we should have communicated that we had not done.

Question two [follow up]: Okay, so next time you might use for example a camera, to talk to each other.

Donkersloot: Could be.

Question two [follow up]: Because I also did a project a few months ago and it was worldwide, and the problem was that you could not speak to everybody because at the time that you were awake, the others were asleep. So we had that problem. The fact that there were several teams working, and the best teams were also the best writers. So they did a lot of emailing in a chat like area that could be read by everybody, but it was only the best writers that had the best outcomes.

Question three: I'm actually really surprised to hear that you were working with a team and if I understood you correctly, you found out along the way that you didn't have the same goals. Can you explain that, how did that come about?

Donkersloot: This was a project in which the other two people I collaborated with had already been working on for awhile. They specifically asked somebody to join in to do the interface because before this they only worked with programmers and the user interface was very un-useable.

Question four: Was this for Sourceforge?

Donkersloot: Yes it has been submitted but it is not specifically...

Question four [follow up]: It isn't for the Sourceforge community?

Donkersloot: It's there and it is available to others but it hasn't been used to collaborate with others.

Question four [follow up]: Oh okay, because Sourceforge is a community of hi-tech script kiddies and programmers. How do you think you can combine them, the creative people and technical people, is there a platform for that? I don't know of a platform, maybe a platform for creatives and programmers could come together, you know what I mean?

Donkersloot: Yes.

Question four [follow up]: I want to know if there is a platform where they can work together...

Donkersloot: Not that I know of.

Question four [follow up]: Because I have a friend that is a coder and I'm a creative...

Matthew Fuller: I think that Sourceforge is used for that but only on a project by project basis, but it is not formalized like a dating agency, you got this set of skill, I got another set of skills lets make programs.

Question five: So what was the result. Was the interface implemented at all or not?

Donkersloot: It's half implemented.

Question five [follow up]: Okay, what does that mean?

Donkersloot: There is a prototype but it is not finished yet. And certain elements of my design are implemented and certain things are changed.

Question five [follow up]: So I wonder how the relationship with you and the programmer was. Did he say what the functionality should be of the software and you had to do the design for it, or was it like you made the design but as well had ideas for functionality and then gave that to the programmer. How did that work?

Donkersloot: The programmer used BitTorrent but built upon that code. So that was for sure our technique, but the way things would be uploaded, for instance what would be, what we wanted to have uploaded that was my input. This was a combination of asking the users and looking at the Opus interface, and from that I made what I thought were the necessary ingredients for Apna Opus. Then I made several PDF wireframes and constantly handed those over to the programmer. I gave the programmer the wireframes in order to ask whether the designs would be technically possible. In the end it turned out that he didn't agree and he also thought I had given him a master plan which he had to follow. Although, yes it was a sort of master plan, it was not intended that he needed to simply implement the designs, but it was meant for discussion. However he never reacted and so then I thought all of the designs were okay, and then upon implementation I found out that he didn't agree and that is where things went wrong. Unfortunately that was at the end of the project.

Question six: Having assisted you in various parts of this, at least trying to get the software, or following the programmers instructions for installing the software on a computer it does seem there is a real disconnection in the whole working practice. Because, I'm someone who's particularly experienced in this area, but I couldn't get it working by reading the programmers instructions. As I remember we tried to install initially on you laptop, and then we ended up installing it on a Linux machine because it wouldn't work otherwise. So it is that grey area, that disparity between, not only in outlining your design but also in understanding each others disciplines, maybe you could comment on that.

Donkersloot: For next time I know for sure that if I work with a programmer I would like to at least meet together once a week, and make what we are doing more transparent. Because now I have the idea that it wasn't really transparent what we were doing, and that made him feel that I was ignorant or that I didn't want to know what he was doing. But that wasn't the case so I think it is really important to just keep talking, even though we are from different disciplines.

Question seven: I just hear the story of you and the programmer, but where is the project manager? I think that is the whole problem, you have to have some kind of steering or some kind of coupling of disciplines. Right now it is just one planet talking to another planet and that is a big problem. Where are the satellites that link the two? I haven't heard you talk about the project manager, and he was there or she was there.

Donkersloot: No it was a she, but she had a lot of other projects to do.

Question seven [follow up]: So it wasn't important for her?

Donkersloot: No I don't think so. I mean it was meant that she would support us for the four months but she did have a lot of projects abroad and a lot of shows abroad so unintentionally she wasn't there enough.

Question seven [follow up]: So it wasn't her objective to make it a success in this case.

Donkersloot: Mmm...

Question seven [follow up]: Well when there are three people working together you can only have a success if everybody is working 100%, otherwise nothing will work out. That's my opinion.

Donkersloot: Yes and no, but I think it still could have worked out if we would have communicated more. Yes, the project manager is there to organize things but I also think that it is all of our responsibility to keep talking.

Question eight: Yes, I think it is important to keep talking but it is also very important that you understand each other and that you have a common vocabulary. I'm not sure in this case you had any tools or methods for making sure of that; even though you did talk with each other it was clear you didn't even understand each other. So I think that it is very important that attention be paid not to just the quantity of communication but the quality and the language of the communication. And here in your case we are talking about a fairly simple collaboration, and I think what is interesting is, even in a simple case a lack of a common vocabulary has clearly lead to a less than successful project. It makes me wonder what happens when we have a wide variety, as we've talked about earlier, of inter-disciplinary, multi-disciplinary, I'm not even sure what the difference is there, but we have many people with many different talents working together and talking their own languages, and trying to come to some sort of come language, I think is a real challenge.

Matthew Fuller: Okay there is more time for discussing things with Victoria later. The next project is very much about an attempt to try and develop a common language in images and plans and structures for developing a social space, so I would like to ask Jeanne van Heeswijk and Dennis Kaspori to please come forward.