Knowing Who Your Testers Are

I don't know about you but as soon as i get involved in a project I think I tend to treat people as if they are co-creators with me. This is great to a point until you start talking to people on the subway about your db design and eliciting their thoughts. Usually around then (or before this), they leave. I don't get invited to parties much.

I love collaboration and teams. I'm a natural extrovert and need people to bounce ideas off and refine thoughts until I want them to go away and leave me alone to build what we just talked about. I really values the random access to colleagues (to a point) that comes from working in a team environment, especially after working for so many years as a "one person shop"

However, last summer it was really hit home to me that you need to know who are your collaborators, who is your client, with whom you can co-develop with and who needs to be presented with a completed or almost completed product. In short, really assess to whom you can show what. The ramifications can actually be pretty huge.

There is a department at work which has historically acted as our testing group. Mostly this was for a few reaons 1) they were a department which was very vested in how things were presented to the outside world 2) they tended to be very detailed oriented and 3) they asked to be a part of things and didn't object to meeting often.

So we started meeting about a project. they had thoughts, I elicited feedback, started building and I thought we were in a cycle of rapid iteration. It was during the exploration of this project that I found a great deal of underlying problems with the data in our db and how some of the core foundation was built which I thought, to make a better platform going forward, we needed to completely change. How we had created the entire site to do what we wanted to do. So we entered into what I thought was a period of rapid iteration. Several meetings, massive changes in interface design and data flow, alterations in business logic which were nothing but helpful in cleaning up some of the data problems and preventing new ones. At the same time, I was rebuilding everything to an object oriented framework from a "silo-ed" application construction. I had a sense of definite progress, upward progression and systemic solutions being implemented.

Then, from my perspective out of the blue, they shut the whole thing down. They said that things were moving slowly, we were chasing out tails and faith in IT was even lower than it was before. I was literally stunned. I'd been working 18 hours a day seven days a week for months. I couldn't understand how the same conversations about the same interfaces with the same people in the same meetings could have resulted in such disparate results.

If the same words mean the different things to the different people it usually goes back to two things 1) they didn't agree on what the words actually meant and 2) the assumptions each brings to the table are different.

Here is what I deduced over the next few weeks / months

1. I was thinking we were in a rapid iteration cycle for each part of the project - they thought that each meeting was going to be a completed product.
2. I was taking into account a system wide approach that was going lay a long term foundation - they thought the project was about 6 interfaces
3. Conversations that I thought (and since then have been proven correct) were very intertwined with what we were doing we perceived as distractions, irrelvant and a lack of focus.
4. What I saw as progress and refinement of a project was leading to testing and feedback fatigue

 The end result though was that we outsourced the project, it still isn't completed and even though I have a fully working application with several auxillary applications supporting it which quantifiably reduce workload and touch points and improve our data quality, no one is interested in even looking at it even though they are reaping the benefits of the project elsewhere through out the org. The work did lay the foundation that I thought it would and has led to other very good things but a great deal of damage was done.

So I started developing a "touchpoint" theory. A touchpoint is the planned number of times a person is going to see the app before it is released. If things don't go well it might increase but it better be for a good reason.

As the designer / developer I am in the middle of a circle. Around me, everyone in the project falls into a outer ring. As the rings get farther away, they are going to see the app less frequently with greater changes and higher polish between meetings. This means a few things

1. You need to know who is in what group - just because someone says they want to be involved doesn't mean that they are on your rapid iteration team. Figure out what that means to them and try to either literally or mentally assign a number of times they will see the app and at what stages.
2. You need to know what you're building first which means better specs, sketches etc. For the developer this probably means being familiar with what the end goals are, the business logic involved, having produced data flow maps (even if the client doesn't see them, you need to to make sure you are asking questions that are going to come up later)
3. You need to maximize the quality of your meeting time with agendas, specific questions and points on which you need clarity.

Last December, we had a different story to tell on a different project. In this case, we were very clear (thanks in part to experience) and told the client three things

1. What we were going to build which included a public interface, a private management portal and an emailing system to use
2. After a few preliminary phone calls we were going to meet three times. Once to make sure we had the description of what needed to be built, Second to show a few working interfaces to make sure were on the right track and a third long session (which we were very clear was going to be a few hours) when we were going to walk through the application as a user and as a manager to make sure that the experience was what they were expecting.
3. After we do the exhaustive walk through we would open it up to their team to walk through as well and get feedback.

In this case we have 4 circles

1. Me the designer / developer
2. My IT group - consulted on some preliminary designs and approaches and was the first round of testing
3. Our primary contact in the department - consulted on prelimary business logic and ideas then was given access once certain levels of "critical mass" were reached.
4. The department who acted as "guinea pigs" for the app as outside users

With the organization and the very clear "this is how many times you are going to see this" approach the project went quite well, is launched and has been in production for months.

Touchpoints in this case were just part of a larger picture of organization and formality. Having formal guidelines lets people know where they stand and allow a fixed point for changing a plan. If there is no structure, no one quite knows where things are and changes can not be as easily communicated.