We start our process by working with the client to define and prioritize as many of the project use cases as possible. We call each of these cases a user story. They are expressed from the perspective of the various user roles on your site. Here are a few examples:
As an anonymous user I want to be able to search for idea proposals by county so that I can see what has already been proposed in my area.
As a registered user I want to be able to add comments to existing proposals so that I can give my feedback and participate in the planning process.
As a registered user I want to be able to thumbs up a proposal so that it has a better chance of being implemented.
As an administrative staff member I want to be notified by email of new community contributions so that I can review and respond to them promptly.
User story generation is a very interactive process between our team and the client and happens in a series of meetings and interviews. We take into account previous work done by the client, collateral documents or internal research and prime the user stories based on that information.
The approved user stories are distilled into a wireframe document (wireframes). Wireframes are a structural map of the site, documenting unique functionality and user experiences. They do not contain any graphical resemblance to the end website. The look and feel of the site will be created later. Several meetings are scheduled between the client and our design team to get feedback. The wireframes are used as a blueprint for the site build.
Our developers define how we are going to meet all of the functionality requirements from the user stories and wireframes. About 50-75% of needs can be met out of the box using our content management system of choice (Drupal). We resolve the remainder by implementing contributed code or through custom development. We prefer to reuse quality pre-existing solutions, contributed code, but frequently modify it to meet specific client needs. We also work through any custom database and file system architecture necessary for managing product data.
Our design team uses the approved wireframes to create layouts for the most significant areas of the site. A design presentation is scheduled to review the layouts with the client and a designated number of hours (provided in the final contract) are allocated for changes from feedback. Once the primary look and feel has been established, one layout is created for each significant secondary page and presented at a subsequent meeting for approval.
While the final design is being created, our development team builds out a functional version of the website, based on the wireframes. Once this site is up and operational we will provide the client work group with access so that you can monitor progress as it unfolds.
Our team will take the final design layouts and apply them as a theme to the website. The theme defines the look and feel for each site, like putting clothes on a person. In addition, we will wrap up any remaining development to finish the site and implement any agreed upon changes from the prior phases.
Before passing the themed site off for testing and review by the client, we will test it internally on all major browsers. We will also assign several team members to go through the site using different user roles (administrator, public user, etc.) and review them for any usability issues. After testing, we will apply any patches necessary to address issues that came up during this process.
We will schedule at least one training with the client to demonstrate all the major components of the site.
Before going public with the site, we ask that the client invest time reviewing and testing as much of the site as possible. Depending on resources, some clients also organize groups from their target audience for testing sessions. After we receive the feedback, we will allocate time for our development team to implement any agreed upon changes.
After launch of the final product, OMF commits to being highly available (response time by end of next business day) for the period defined in the contract (generally 2-4 weeks). This includes allocating time as needed from our development or design team to resolve bugs quickly, or make adjustments based on user feedback.
After the two week period, OMF will request final product approval from the client.
Ⓒ 2021 Open Media. All Rights Reserved.
Open Media is a not-for-profit, 501(C)(3) corporation