WORKING WITH A WEB DEVELOPER - 5 THINGS TO CONSIDER
- Your Mission Comes First - Find a Developer Who Gets It
- Consulting - Refine and Focus the Project
- Leverage - Don’t Reinvent the Wheel (or Any Other Tools)
- The MVP - Minimum Viable Product, Phases, and Other Ways to Keep Your Budget on Track
- The “Goldilocks” Way - This Developer Is Just Right
This topic was presented by Scott Anderson from Room 34. His handout laid out Things one through five really well, and copying the material here would be repetitive. Instead, you can look it over on Room 34
. I highly encourge reading through it. It covers key points of choosing and engaging with a developer.
Thing 1 should be emphasized: a mission-driven developer can be key to success. It is especially the case for organizations that will have trouble paying the industry standard minimum for a redesign ($2,000 for a barebones site using a prebuilt template). If you are seeking services for below standard rates, find someone who values what you do, and is willing to adjust their pricing because they support your mission, or because they consider your project good experience for them. Several of the nonprofits I work with pay contract staff less than market rates, or rely heavily on volunteers to complete their projects. The most reliable work comes from participants who share your desire for the organization to succeed, and value its role in the community.
REDESIGN - 5 THINGS I'VE LEARNED
(Brooke Thomson at Annex Teen Clinic)
- Managing Expectations
- Approval / decision matrix / hierarchy
- Staff roles & responsibilities
Your staff / members should be able to agree on who your audiences are. To keep it manageable, have not more than three audience groups identified. Also, involve audience members in the user testing process (testing your site). Identifying audience needs and wants was discussed at some length in the Balancing Goals
section of Design for Nonprofits (Part 1). Instead of repeating that information here, please refer back to that post.
2. Managing Expectations
What needs to be negotiated and how to negotiate? After you have gotten you staff engaged in planning a redesign, you may need to mitigate expectations. During your brainstorming sessions, have a "why" behind the approval or denials of ideas. Everyone will have functionality or features they want to see on the site, but as the Stones' song goes, "No, you can't always get what you want". Having cost examples ready for review is one way to help people understand why something will or won't work. Staff should also be made aware that project decisions require approval, and that approvers will have rationale for their choices.
3. Approval / decision matrix / hierarchy &
4. Staff roles & Responsibilities
Who's responsible for what? At the start of a redesign project, figure out what decisions need approval (e.g. contracting a developer, setting a budget, content choices) and determine who is responsible for those approvals. The approver could be a staff member, or perhaps it requires a board vote. A suggestion based on my own experience, the more parties that are involved, the more cushion you will need to add to your timeline for the project start and or completion. Getting a consensus can take considerable debate or negotiation if more than one department or committee is involved. Beyond approvers, the decision matrix for a redesign can include a project manager, content manager, and testers. Small teams are useful in a redesign decision matrix.
Who should be on your decision teams? Your website may have more content than you realize. A content team could be necessary for managing it. Keep in mind, content teams should be people with their boots on the ground (working out your org's mission with its audience as opposed to a grant writer). Also, having a content team manager will help you maintain a consistent voice across the site. For testing teams, include you audience if you can. It goes without saying that they're the ultimate goal in making your site usable and useful.
Do your homework! Once roles and teams are assigned, prepare for your new tasks. There are many resources to help fill the knowlege gaps. This includes countless online resources to help you form effective test cases or develop a project checklist. In the Twin Cities, there are many in person classes geared at nonprofits. Also, keep in mind that content creation and curation often will take longer than expected.
Plan integrations finacially and think about the future. You might not be able to get all of the functionality you want at once. In that case, do the MVP (minimum viable product) up front, and plan the rest of the features in phases - three, six, or nine months out. As discussed in the Room 34 presentation link above, MVP is "absolute essential elements you would need for your website to accomplish its goals". When considering the future of your site, plan for its maintenance. It should be easy to update for non-techies, so it can stay fresh between overhauls. As pointed out by Scott Anderson during Q&A, as part of a project, a developer should have training sessions, documentation, and make as much as possible on the site editable.
Have a strategic technology plan. You can make site overhauls part of a work plan, based on your tech budget, but a typical schedule is every three years. To this end, have a technology reserve fund to which you make monthly contributions. You can also seek grants to redesign your site. Having a techonolgy plan as part of a strategic plan will reinforce the importance of your tech.
I hope you found parts 1 and 2 of this post useful. If you have any questions, feel free to contact me. Check back in January for another post on local (Twin Cities) resources for learning web development and maintenance tools. Cheers!