Project: William Davidson Institute
Step #1 – Hold Kick-off Meeting & Understand Expectations
We worked with WDI’s Base of the Pyramid Initiative (BoP) team and their Impact Assessment Tool, which is used to assess effectiveness by measuring changes in critical dimensions of household well-being. Going into it, we knew our client’s goals were:
- Create a website focused entirely on the BoP Initiative
- Increase the availability and use of the Impact Assessment Tool by making an interactive version available through the BoP website
Our first step was to meet with our two main contacts for the project, a Research Associate and a Research Assistant. They explained what the BoP Initiative did and how they worked with their partner organizations. We established that the primary audience for the site would be organizations or ventures that work to alleviate poverty in the developing world. They asked us to keep two things in mind:
- Maintaining visual continuity between the WDI website and the BoP website
- The variable connection speeds of the BoP’s partners located across several continents
We asked them who the project stakeholders were, how the website would support their goals, who would use the website and what they would use it for, what the desired functionalities of the website were, and what the trajectory was for the website over time.
Step #2 – Establish Scope
Given that we were learning to work with Drupal in parallel with the unfolding of this project, before we committed to anything with our client, we first ran our proposed scope by our instructors for their opinion on what we would be able to deliver by the end of the term. We determined that we could build the website pages they’d requested, as well as the first two components of the Impact Assessment Tool: the impact assessment grid and the survey question generation. The website would have log-in functionality and we would effort to find a Drupal theme that bore a resemblance to the layout and color scheme of the WDI website. Optimizing the site for dial-up speeds was beyond our capacity, but we would take performance into consideration in our design.
Step #3 – Craft Personas & Usage Scenarios
Based on conversations with our client, we developed three personas and usage scenarios that represented distinct future users. The personas varied in terms of their comfort with technology, whether they owned a home computer, the speed of their internet connection, whether they entered field data manually or via upload, and the types of data they accessed through the website.
Step #4 – Draft Information Architecture & Workflow Analysis
At this point, we drafted an Information Architecture document that defined the seven content types that would be present on the site. Much of the site content would be added by WDI admins or partner organizations. For each content type, we named its metadata and fields, and captured their characteristics, such as whether it was required, who would supply it (admin, user or auto), who it would be visible to, whether it required a login, and whether it required approval before being published. We also drafted a site navigation scheme and worked with our client to translate business-speak page titles such as ‘Collaborative Engagement’ and ‘Value Proposition’ to the friendlier ‘How We Engage’ and ‘What We Bring’.
The Workflow Analysis document defined the roles associated with the website as well as the privileges associated with each. We also laid out the processes for approving, classifying and removing content. We then described 11 workflows, naming the actors, preconditions, post-conditions, normal steps, and alternative steps for each.
(Side note: The most valuable lesson we learned at this stage was the importance of sending these types of deliverables to clients in advance of meeting to discuss them. The level of detail here is immense, and the need to have time to review it before discussing it is obvious in hindsight.)
Step #5 – Select Modules & Create a Working Site
Our next step was to select, enable and configure the 40 modules needed to provide the site’s functionalities. These modules would do everything from providing discussion forums to adding WSIWIG text editors. We also chose a theme that provided basic visual design. At this stage of the project, we realized that our team lacked the skills required to build the first two components of the Impact Assessment Tool and we had to break this to our client. The best we could do was create a placeholder module with the basic tables the first component of the tool would need.
Step #6 – Draft Final Documentation & Training Materials
Our final documentation included final versions of the documents we’d sent to our client throughout the project, along with step-by-step instructions for 11 tasks associated with administering the site. We also provided information about resources at the School of Information for the future development of the Impact Assessment Tool.