Skip to main content

Web Discovery Questions

Jesus Film Project Website Stakeholder Discovery Document Template

Purpose of this document

This discovery document is designed to help Jesus Film Project  web team gather clear, consistent, and actionable website requirements from internal stakeholders and teams. It is intended for use in stakeholder interviews, intake meetings, workshops, and planning discussions so that website decisions align with ministry goals, audience needs, global realities, and operational constraints.

Both stakeholders and PMOs should fill out the ir respective sections

Rubric for Website Development

Rubric for Website (including webpages and CPT) Development or Feature. Learn more.

1. Stakeholder Overview 

Why this matters:

This section establishes who is making the request, what team they represent, and what role they play in the success of the initiative. It also helps clarify decision-making authority, influence, and accountability early in the process.

Stakeholder details

  • Stakeholder name:

  • Title / role:

  • Team / department:

  • Date:

  • Facilitator:

  • Related initiative / project name:

  • Other involved stakeholders:

  • Level of decision-making authority:

  • Regions / languages / ministries represented:

Discovery questions

  1. What team or ministry area do you represent?

  2. What is your role in this initiative or request?

  3. What responsibility does your team have for the website, if any?

  4. Who else should be involved in this conversation?

  5. Who is the final decision-maker for this request?

  6. Which departments, regions, or language teams are affected?

  7. Is this request driven by a specific campaign, strategic initiative, ministry need, or operational issue?

  8. Has this need been discussed before? If so, what was decided?

2. Ministry and Organization Goals

Why this matters:

Website requests should support broader ministry and organizational objectives, not just isolated preferences. This section helps connect website needs to mission impact, strategic priorities, and measurable outcomes.

Discovery questions

  1. What ministry objective is driving this request?

  2. What organizational or team goal does this support?

  3. Why is this important now?

  4. What problem are you trying to solve, or what opportunity are you trying to capture?

  5. How does this request support the mission of JFP?

  6. How does this request serve evangelism, ministry partnership, resource distribution, or disciple-making?

  7. What outcome would make this request successful from your team’s perspective?

  8. Is this tied to a larger strategic initiative, annual objective, or leadership priority?

  9. What would happen if this request is delayed or not implemented?

  10. Is this a short-term need, long-term need, or both?

3. Audience and User Needs

Why this matters:

Effective website decisions begin with a clear understanding of who the user is and what they are trying to accomplish. This section helps ensure requests are rooted in real audience needs rather than internal assumptions.

Primary audiences to consider

  • Decision-makers at other Christian ministries focused on evangelism

  • Individual believers who want to evangelize more effectively

Discovery questions

  1. Who is the primary audience for this request?

  2. Is the audience external, internal, or both?

  3. What type of ministry leader, partner, or user are you trying to reach?

  4. What does this audience need most from the website?

  5. What are they trying to do, learn, find, or accomplish?

  6. What are their likely pain points, frustrations, or barriers?

  7. What questions do they typically have before taking action?

  8. What level of awareness or familiarity do they already have with JFP?

  9. Are there audience differences by region, language, ministry maturity, or church context?

  10. What might success look like from the user’s point of view?

4. Key Website Pain Points

Why this matters:

This section surfaces what is currently not working so teams can address root issues rather than symptoms. It also helps distinguish between perceived problems and truly high-impact barriers.

Discovery questions

  1. What is not working well on the website today?

  2. Where are users getting stuck, confused, or dropping off?

  3. What complaints, feedback, or recurring questions do you hear from users or internal teams?

  4. Are there gaps in content, functionality, navigation, or messaging?

  5. Are there parts of the site that feel outdated, unclear, hard to use, or misaligned?

  6. What internal processes make it difficult to support this area of the website?

  7. What workarounds are teams currently using?

  8. What is the biggest pain point you would fix first?

  9. Are these issues affecting one audience, multiple audiences, or global users broadly?

  10. Which pain points are urgent versus inconvenient?

5. Content and Messaging Needs

Why this matters:

Content is often the clearest expression of ministry value, clarity, and trust. This section helps identify what content is needed, who it is for, and how messaging should support both ministry impact and user action.

Discovery questions

  1. What content is needed to support this request?

  2. What existing content already exists, and what is missing?

  3. Does the current messaging clearly explain the value of this ministry, resource, tool, or initiative?

  4. What does the audience most need to understand, trust, or believe before taking action?

  5. What specific pages, content types, or assets are needed?

  6. Are there key calls to action that need to be strengthened or clarified?

  7. Does the content need to serve different audience segments differently?

  8. Are there theological, ministry, or brand considerations that need to shape the messaging?

  9. Who owns the content strategy, writing, review, translation, and updates?

  10. What content should remain evergreen, and what content will require regular maintenance?

  11. Are there stories, case studies, testimonies, or field examples that should support this content?

  12. What tone should the content reflect for this audience?

6. Language and Localization Considerations

Why this matters:

Because JFP serves a global audience, language and localization cannot be treated as afterthoughts. This section helps clarify translation needs, regional differences, cultural adaptation, and operational realities across markets.

Discovery questions

  1. Which languages are needed for this request?

  2. Is direct translation sufficient, or does content need cultural adaptation?

  3. Are there region-specific user needs, examples, offers, or calls to action?

  4. Which markets or countries are most important for this initiative?

  5. Are there languages that should be prioritized first?

  6. What is the translation and localization workflow today?

  7. Who reviews translations for quality, clarity, and theological accuracy?

  8. Are there known challenges with multilingual publishing, governance, or maintenance?

  9. Will all features and content be available in all languages?

  10. How should the site handle language selection, fallback content, and untranslated pages?

  11. Are there localization considerations related to imagery, examples, ministries, testimonies, or terminology?

  12. What would make this experience feel more locally relevant and useful?

7. Functional and Feature Requirements

Why this matters:

Stakeholders often express needs in terms of desired features, but the underlying requirement may be different. This section helps clarify what users need to do, what the business needs to support, and what functionality is essential versus optional.

Discovery questions

  1. What does the user need to be able to do on the website?

  2. What feature or capability is needed to support that action?

  3. Is this a new feature, improvement to an existing feature, or replacement of a current process?

  4. What specific functionality is required?

  5. Are forms, downloads, search, filtering, account features, integrations, or content personalization involved?

  6. Does this request require different functionality by audience, language, or region?

  7. Are there required user journeys or business rules?

  8. What systems, teams, or workflows would this feature affect?

  9. What does a minimum viable version look like?

  10. What is essential on day one, and what could be phased later?

  11. Are there accessibility, security, privacy, or compliance considerations?

  12. What feature requests are truly necessary versus simply desirable?

8. UX and Journey Considerations

Why this matters:

A website can have good content and strong functionality but still fail if the user journey is confusing. This section helps identify how users move through the site, what actions matter most, and where better clarity or guidance is needed.

Discovery questions

  1. What is the ideal user journey for this audience?

  2. What are the key entry points into this experience?

  3. What action should users take next after landing on the page?

  4. Where do users need more clarity, reassurance, or direction?

  5. What steps in the journey feel too complicated, long, or unclear?

  6. What information does the user need first, second, and third?

  7. What questions or objections should the page or experience answer?

  8. Are there important journey differences by device, language, or geography?

  9. Should the experience drive exploration, conversion, engagement, or relationship-building?

  10. What would a better user experience look like in practical terms?

  11. Are there known navigation issues affecting this journey?

  12. What examples from other sites or experiences feel relevant, useful, or inspiring?

9. Technical / Platform Considerations

Why this matters:

Even strong ideas can fail without technical feasibility, platform alignment, and realistic implementation planning. This section helps capture constraints, dependencies, and opportunities early enough to plan wisely.

Discovery questions

  1. Are there technical constraints we need to know about?

  2. Does the current platform support this request?

  3. Are integrations required with CRM, analytics, DAM, translation systems, forms, email, or partner tools?

  4. Does this request affect performance, security, scalability, or maintainability?

  5. Are there known issues with the current CMS, templates, or publishing workflows?

  6. Does the request require custom development, third-party tools, or vendor support?

  7. Are there mobile, browser, or device-specific considerations?

  8. Are there accessibility standards this solution must meet?

  9. Is there existing technical debt that could affect this request?

  10. What internal technical resources are required to support this?

  11. Are there data privacy, consent, or regional compliance issues to consider?

  12. What technical assumptions need to be validated before moving forward?

10. SEO, Search, Analytics, and Measurement

Why this matters:

A ministry website still needs to be discoverable, measurable, and optimizable. This section helps ensure requests consider findability, onsite search, performance data, and meaningful success indicators from the start.

Discovery questions

  1. How should users find this content or experience?

  2. Is organic search an important traffic source for this initiative?

  3. What search intent is this content or feature meant to serve?

  4. Are there important keywords, topics, or questions this should address?

  5. How should internal site search support this experience?

  6. What analytics are currently available for this area?

  7. What data do you already have about user behavior, performance, or demand?

  8. What metrics would indicate success?

  9. Are conversions clearly defined?

  10. Do we need event tracking, funnel tracking, scroll tracking, form tracking, or campaign attribution?

  11. Are there SEO risks such as duplication, localization complexity, or weak information architecture?

  12. What performance benchmarks or baselines should we compare against?

11. Governance, Approvals, and Ownership

Why this matters:

Many website issues are not caused by technology, but by unclear ownership and inefficient workflows. This section helps define who is responsible for decisions, content, approvals, updates, and long-term stewardship.

Discovery questions

  1. Who owns this initiative from a business or ministry perspective?

  2. Who owns the content once it is published?

  3. Who approves strategy, content, design, theology, and technical implementation?

  4. What teams need to review or sign off?

  5. What is the current workflow for creating, reviewing, translating, and publishing content?

  6. Where do delays usually happen?

  7. Who is responsible for ongoing maintenance and updates?

  8. How often will this need to be reviewed or refreshed?

  9. Are there governance policies or standards that apply?

  10. Is there confusion today around roles, approvals, or decision rights?

  11. What would make the workflow more efficient and sustainable?

  12. Who will be accountable for outcomes after launch?

12. Risks, Blockers, and Dependencies

Why this matters:

This section helps teams anticipate what could slow down, complicate, or weaken implementation. It brings hidden concerns into the open so they can be addressed before they become project failures.

Discovery questions

  1. What risks do you see with this request?

  2. What could prevent this from succeeding?

  3. Are there budget, staffing, timing, or technology constraints?

  4. Does this depend on other teams, systems, approvals, or external partners?

  5. Are there unresolved strategic questions that need leadership input?

  6. Are there theological, brand, legal, or cultural sensitivities involved?

  7. Is this request dependent on translation, content creation, or technical infrastructure not yet in place?

  8. What assumptions are we making that may not be true?

  9. What could cause delays after the work begins?

  10. What previous lessons or failed attempts should inform this effort?

  11. What is the greatest implementation risk?

  12. What would reduce uncertainty before moving ahead?

13. Priority Level and Implementation Readiness

Why this matters:

Not every request should be treated equally. This section helps distinguish strategic, urgent, and high-impact work from lower-value ideas or requests that are not yet ready for execution.

Discovery questions

  1. How important is this request relative to other ministry and website priorities?

  2. Is this urgent, important, or exploratory?

  3. What is driving the timeline?

  4. Is there a deadline, event, campaign, launch, or external dependency?

  5. What is the cost of not doing this?

  6. What is the expected impact if this is implemented?

  7. Is the request clearly defined enough to move forward?

  8. What information is still missing before this can be scoped?

  9. Is content ready, or still being developed?

  10. Are stakeholders aligned on the need and desired outcome?

  11. Could this be delivered in phases?

  12. Is this a must-have, should-have, could-have, or not-now item?

Priority assessment

  • Priority level:

  • Business / ministry impact:

  • Audience impact:

  • Urgency:

  • Level of effort:

  • Readiness status:

  • Recommended phase:

14. Summary and Recommendations

Why this matters:

A discovery process is only useful if it leads to clarity and action. This section captures the most important findings, recommended next steps, and decisions needed to move forward.

Summary fields

  • Request / initiative name:

  • Stakeholder / team:

  • Primary audience:

  • Core problem to solve:

  • Desired outcome:

  • Key user need:

  • Key website need:

  • Key risks:

  • Key dependencies:

  • Recommended priority:

  • Recommended next step:

  • Owner:

  • Proposed timeline:

Summary questions

  1. What is the core need behind this request?

  2. What problem are we solving for the audience and the ministry?

  3. What requirements are clearly defined?

  4. What needs more validation, research, or alignment?

  5. What should happen next?

  6. Who needs to make a decision?

  7. What should be prioritized now, later, or not at all?

  8. What recommendation best balances ministry impact, user value, and operational feasibility?

Back to top