View source for How to prepare for a website development project from the org side

Goals for this session

* Want to hit the methodology, make sure we have clear understandings, how to convey methodologies clearly to nonprofits
* Talk about pitfalls and challenges in different stages of website project methodologies


== Phases of a Project: typical methodology ==


* '''Internal Planning'''
** Look at big picture: clarify goals, identify audiences, inventory the content on a current site, understand who you'll be working with
** From developer perspective, organizations might undervalue this phase; orgs jump into RFP and contract processes without fully exploring internal needs, constraints, etc
** Important to make sure that the person taking on point person responsibilities has capacity and skills needed.
** In taking inventory of current website, when thinking about what the new site will be, there's an idea about new content but not a planning process around actually writing that content. Important to check in on how to create all that new content early on.
** Question: what do you say to orgs that want an excessive amount of functionality, too much content, etc?
*** Think about whether the person who's coming to the website already knows what they're looking for; think about target audiences, how the org is perceived or wants to be perceived; think about how to provide the right design, functionality, and content to meet the needs and expectations of target audiences. For many nonprofits, site visitors need to be invited into the space, helped through the content on the website; the design needs to be robust, the considerations around every element are more important.
*** Need to consider needs and perspectives of different audiences.
** Think through who the people will be in the process: who are the participants from your organization, what are their roles? Defining those early lead to more successful implementations. When roles are greyish, when decision makers come in at the end of the process, it can be difficult.
** Think about specific decision points when those stakeholders will come into the process.
** Normally insist that any stakeholder that makes decisions on anything is involved in the process from the very beginning, so there's no 11th hour changes.
** Having documentation about decision-making process agreements is important to look back to.
** If this internal planning process doesn't happen ahead of time, it often has to happen during the paid discovery process. That can be good in that a consultant might have good ways to organize
** Design Action has organizations fill out a questionnaire at the beginning of the process, even before the estimation process; if all stakeholders read and respond to the questionnaires, it helps avoid pitfalls down the road. It also helps organizations realize whether they need a lot more preparation before entering into a website creation process with consultants.
** That approach indicates consultants' investment in making sure the project goes well for the client.
** Focus on outcomes instead of tech tools; be as specific as possible about goals and metrics for success.
* '''Discovery'''
** Typically happens after a contract is signed, moving into a project with consultants.
** Key goals: Make sure the firm and the organization have understanding of the organization's needs, audiences.
** Deliverables include a site map, list of key functionality, wireframe of key elements that will appear on the site and inform the next phase of the design process.
** So much of what's identified in the wireframe shifts when real content comes into play; try as much as possible to get real content in the wireframes, plan around meeting content needs that are being built into the plan or functionality.
** Put as much real content into the wireframes as possible (but it's not always possible).
** Get folks to actually come up with real text that they'd want to put on sites, e.g. from print materials and brochures, to get a better understanding of what the content will be.
** No matter how much you plan, things will change as functionality is built and content is added; important to design flexibly.
** It's great when designers and developers work together throughout the website process, all the way through the launch and support stage; design also needs to be QAed after the development and content population processes are done.
** Use graphic representations/infographics during this discovery phase to help folks break down and understand.
** Oftentimes feedback during the discovery process is disparate; important to ask organizations to come back to the consultants with coherent, consolidated feedback.
** Unless a consultant is deeply involved or embedded in the organization, they might not be able to consolidate conflicting perspectives and the organization might have to be pushed back on to filter and distill those conflicts.
** If there's a request to consultants to facilitate a process, that can be fine given the right resources and time. But consultants should avoid coming back and saying that one internal organizational party is wrong and the other is right; breaks down trust.
** Assessing organizational capabilities to keep up with, maintain, and use features that are being planned.
** Define roles and responsibilities about how the website is going to be managed after the launch
** A website project isn't a success if it's built perfectly but no one uses it; our shop is starting to work with clients to plan their website content & maintenance process and workflow integration to avoid that.
** Developing guidebooks (documentation) to pass down to people on how to use the site being built; might be good to create at least a boilerplate to give to clients that organizations can then customize themselves to suit their particular needs.
** Each organization's culture will determine how to work out organizational capacity, how to set a framework for how it's going to work from the beginning, how to set boundaries.
** Difficult when the process gets gummed up, feels like pulling teeth to get the necessary feedback; it can be good to work out a process where not everyone has to be involved in every decision or every detail, which can bog down the process. Good to have places for input from all stakeholders.
** The website process is always an additional task on the plate of someone working at a nonprofit; they have a lot of other stuff going on, they need to figure out how to fit this into their workload. Keeping momentum up can be challenging.
* '''Design'''
** Process: drafting and working on design mockups, revising mockups based on feedback, and finalizing mockups.
** Use everything that's come out of the earlier stages in the process.
** If a key stakeholder is not involved in the design process but then comes in at the end, that can be really difficult and frustrating for the designers.
** Making sure that roles are really agreed upon and that there's buy-in.
** All the stakeholders can define the personality of the larger project, high-level stuff; then the nitty-gritty details can be handled by less decision makers.
** Wireframes are about layout; there's also some low-fidelity, greyscale design in between wireframes and full-on mockups.
** Wireframes should deal with the hierarchy of information and how it's organized; even low-fi designs can distract.
** Challenge of balance between design complexity and ease of updating.
** Question: how often to you recommend that an organization do an overhaul of the website and change the look?
*** As soon as the website is not meeting the goals of the organization.
*** If the goals of the organization change, it might be important to re-inventory and wee whether a website look overhaul needs to happen.
*** Sometimes organizations choose to do mini-sites for specific projects or campaigns, rather than overhauling the entire main website.
*** Aspiration Tech has some good tools for organizations: user stories, understanding value that people derive from the site.
*** Before building out a massive
*** Big Duck NYC has a "Is it time to rethink your website" flowchart: http://www.bigducknyc.com/blog/is_it_time_to_rethink_your_website
** How do we help organizations better communicate feedback around design?
*** Ask really specific questions, very answerable that aren't about whether it pops but are about what needs to be emphasized more, more easily accessible, etc; ask for meaningful feedback directly related to goals, audiences.
*** When there's a lack of shared language, it gets into very specific micromanager-type changes; that's often a sign that something isn't working and a solution is being sought. Sometimes a response from designers can be to provide alternative solutions that might achieve goals better, to help suss out what's really not working.
** Design Action Collective's questionnaire includes detailed questions about design: give examples of websites of organizations you want to be aligned with but distinct from, organizations that might be working against you, etc to help inform the design process.
* '''Development'''
** Elements of development process:
*** Set up development environment
*** Build out site structure, information architecture
*** Address search engine optimization
*** Do any custom coding necessitated by the features & functionality list
** Important to have reviews of the functionality being built throughout the process
** Set up check-in points throughout the development process; make it clear up front how the workflow will go, where key input points will be.
** One approach: biweekly check-ins with the client to review and get feedback/sign-off on the work that's been done during the past two weeks; regularly scheduled check-ins are easier to manage, helps with accountability on all sides of the process to have such frequent check-ins built in; do budget checks early and regularly, not when 
** Shared project management tools and lists of to-dos with the client; regular budget reviews & check-ins
** Do staged billing on a monthly basis, helps the organization not lose momentum.
* '''Content Population'''
* '''Quality Assurance'''
** Usability testing is different from QA, but is possibly a part of QA
** Testing shouldn't just be dumped on the organization with a request of a list of bugs
** Desire for feedback from organizations: what do you expect? How do you look at the QA/testing process? How do you budget for it and make sure there's time available for it?
** Development shops often do testing themselves during the development process
** Contracts explicitly list what's on the hook to test, e.g. what browsers and OS will be tested (and which won't be.)
** Testing is done when a client signs off on the project or on discrete parts of the project. What are tools do we use to help clients go through the process?
*** Do lots of training, try to get clients to add some of the content themselves. The more you're involved in the dev process & adding content before the site goes live, the better off you'll be.
*** 30-day grace period; after the site goes live, organizations can contact support, won't be charged.
** Do folks have different website/organizational audiences or constituencies test the site?
*** One shop has stopped doing that, because many times the folks doing that sort of beta testing had no idea about all the thoughts or reasons for why the site got built in a certain way. Feedback that would come back that could totally derail the process without understanding why things were done that way.
*** Another shop: usability testing and QA focuses more on the site users & clients, less on the experiences of site visitors; it feels like QAing/UX texting for site visitors can happen 
*** Userlytics.com -- user experience testing that can be done pre-content population.
*** With a CMS, some QA is site-specific and some is CMS-specific.
** Is it possible to outline a coherent QA process for clients?
*** Folks come to Aspiration Tech with those questions a lot, "Is the site done?" ; they respond by referring them to site goals and user stories, and if the site does what those stories ask for, the site might be done!
*** Does there need to be a basic set of user stories for every project? Or are user stories only useful when you're building out custom tools?
*** Aspiration Tech's approach: Figure out who your top three audiences are and your top 1-3 editors are; write user stories for those; ask for no more than five user stories in general. Figure out most important target audiences rather than trying to meet goals for everyone.
*** If those user stories are decided on really early on in the process, agreed to by everyone, at the end of testing you can assess completion against those user stories and goals.
** Important to have a shared understanding of when the site is "done."
* '''Launch'''
* '''Support'''
** One shop rotated support responsibilities; now there's a team that specifically provides report. That's difficult when a client is used to talking with the developer and is now being directed to the support team.
** Shop: we charge for support; there are two kinds: it's broken, we don't know how to use it, or something brand new. Debates about what support to charge for and what not to charge for.
** Another shop: moved from a consultant-based revenue model to a product-based revenue model; pricing is fixed up front, based on organizational budget, which makes the on-boarding process much easier. The downside is that going over time or over budget, you just have to eat that.


takeaways for the group report back:

* Focus on goals and outcomes
* Keep communication flowing, which helps with accountability
* Identifying and agreeing on roles and key stakeholders
* Having a discovery questionnaire that organizations take during estimation, before contracts are signed