How many times have you filled out a form online? We do it all the time. We fill out online surveys. We purchase goods online. We pay bills, do personal banking, and book travel, all with the ease of web-based forms. The likelihood is that most people don’t concern themselves with those forms and what it took to create them. Now, program providers are stopping to think about exactly that, and from my own experience, I can say that I had no idea what I was getting myself into.
Ask a program provider about the piece of their work that can be most challenging. You may expect it to be curriculum creation, or hiring the right program leaders. Yes, those are crucial elements to any successful program, but just as important is collecting a significant amount of very detailed information from each participant before anything actually takes place on the ground. We need to keep in touch with participants, keep them safe, and gather background information to help better inform our work.
It is the responsibility of the program provider not only to gather this information, in a timely manner, but also determine how best to do so.
A year and a half ago the Service Learning staff at PJA & JFSJ (Now: Bend the Arc) were on the precipice of a major program expansion and recognized that our method of obtaining participant information was quickly going to become a burden. The two members of our team most responsible for the application were tasked with designing a new system and collaborating with the developers on what would best serve our department. We started dreaming up grand plans for what an online application could and should look like. And in our minds, it wasn’t even going to be that hard to create! We would find a developer, tell them what we wanted, and boom, it would just happen. Then again, what did we know? Neither of us are web or application developers.
We did have this sense that the development aspect would need to be very specific, so we quickly set out to create diagrams and flow charts that outlined the steps we wanted participants to go through on their journey to completing our online application. We spent hours reviewing the questions we asked and the points at which we asked them. We researched other applications to see how they worded questions and what was required versus optional. We made list, upon list, upon list.
First was our flow chart: We wanted to make sure that our developers understood the process that the application had to follow. Then we realized there were things that would be needs, and things that would be wants. We thought we’d be making it easier on the developers if we categorized everything for them.
I have to admit, when we finished this list, we thought the task would be fairly simple and were quite proud of ourselves for thinking through all of the little details. We would be working with the developer who was already designing our organization’s website. To us that meant they knew our work, and collaboration should have been easy. But we didn’t want to be naïve. This was not the type of thing that could be whipped up in a month. We thought there would be a few months of work, a little bit of time for testing, and then we’d roll it out. I don’t think I have ever misjudged something to such a great extent.
My colleague and I were introduced to our developers, Jaki Levy and Sam Frank, from Arrowroot Media, and they were eager to help us out. I will admit that the first couple of months of working together were a little rocky. We just weren’t connecting on what needed to be done. It seemed like there was misunderstanding after misunderstanding. Jaki and Sam were great about asking a lot of questions, but they weren’t the right questions. I would imagine if we turned the question around, they would say the same thing about us. Or maybe they would just say that we had unrealistic expectations.
I quickly realized the biggest stumbling block we faced: we were not speaking the same language. By that I mean that we didn’t understand each others’ needs. In order for them to truly comprehend what we needed from our system, they had to understand the ins and outs of our programs and we needed to become more familiar with the functionality of the back-end of the application. They kept asking questions about when the applications would open to participants and when they would close, and I kept telling them that the applications really never closed until a group actually left for their program. They kept talking about the trigger emails that would automatically go to my team when applications came in and I wanted to know how the staff from Hillels and synagogues would keep track of the information. We did the only thing we could do at that point – took a step back and walked Jaki and Sam through all the details of how our programs work.
We started by describing the relationships we hold with Hillels and synagogues across the country. We explained the timeline through which we set up those relationships and at what point we determine that we will partner with them on a program. We explained how they go through their recruitment process and what our role becomes through that time. Jaki and Sam needed to understand not only how our programs ran, but also the timing. All campus Hillels need to be able to have access to their applications when school starts in September, regardless of whether their program takes place in January or March, and not all January or March programs happen at the same time. We could have three schools out one week, five out the next, and none out the next. They will all recruit up to the very last day possible, meaning we don’t “close” their applications. They had to see that we, the staff at PJA & JFSJ, don’t know the participants who are being recruited, and therefore the Hillel and synagogue staff on the ground need to have access to the list of people who have applied for their respective programs so that they can be in touch with their participants directly.
Then we had Jaki and Sam come into the office. They kept throwing around terms like Drupal platform, trigger emails, auto-generated user IDs, discrete user logins, etc. I knew what the words meant, but I had no context for them. They were building something that I couldn’t visualize. We had to sit down together so they could map it out for me. I remember looking at the notes Jaki and Sam took in that face-to-face meeting and thinking for the first time that we were on the same page. They understood how our program worked and, as such, what we needed in an application. We understood generally how our application would be built.
Moving forward we knew we were going to need a visual platform to make our collaboration work. It wasn’t realistic to think that Jaki and Sam would come into our office every time we needed to talk, but my colleague and I had to “see” what they were talking about. They decided to put screen shots into PDF and PowerPoint presentations for us. That way when we were on the phone or in web conference together, we could all view the same mock-up and have equal points of reference. Their screenshots came complete with a final view and margin notes to highlight the key points we were focusing on during that call. It made everything much smoother and faster for us.
Finally, the day came when we had something to test. For this, the group decided we should be face-to-face. The four of us were set up in the PJA & JFSJ conference room with numerous computers. We wanted to ensure that everyone could see all aspects of the work. Having multiple computers engaged in the testing process was the best way to mimic multiple users testing our product. Jaki and Sam sat with us as we manipulated the application as participants, partnering staff, and PJA & JFSJ staff. Until now we had only ever seen screenshots of the back end of our application. The explanations were very helpful, but manipulating the application was another issue. Jaki and Sam were able to physically show my colleague and me what needed to happen in our work at all steps of the process. We could troubleshoot, we could see not only the external pages, but the internal pages, and we could gain a deeper understanding of what we needed to do when our partners called us with questions or problems that their participants encountered.
I would love to say that a week later our application launched. In reality, it took about four more months and more changes than I can count. When we look back at our criteria, shown above, we definitely accomplished most of it. Anything that was a fundamental need was achieved, sometimes in a different form than we had anticipated, but it’s there nonetheless. And at the end of the day it’s a work in progress. We’ve received a lot of feedback, but feedback is good. We will spend hours poring over the feedback and talking it through with the whole team, not just so that we can come up with solutions, but so that we can ensure that everyone is on the exact same page regarding necessary changes. At the end of the day if we aren’t all speaking the same language, this application will never achieve its goals.
 The screenshots above were created before the merger between Jewish Funds for Justice and the Progressive Jewish Alliance. As such, our organization is referenced as solely as JFSJ, but all subsequent work and the live application, references our current name, Bend the Arc.