Discover problems a potential ministry partner might be experiencing through relationship building. Focus on problems that hinder the ministry they’re doing and then begin exploring how a tech solution might solve that problem.
Two examples:

• C2C Story: Our partner illustrated a method of evangelism with the intent to print to paper. By developing a digital solution, we multiplied the effectiveness of this outreach tool.
• Fihristi: Our partner was struggling to create a website for a new Bible study resource. We were able to take their research and deliver not only a web tool, but also an app version now available on iOS and Android devices.

Result: A partner that wants to explore how eDOT might be able to partner with them.

Responsible	Accountable	Consulted	Informed
eDOT Partner Owner	eDOT	UI/UX

Define the potential partner’s

• Overall Mission/Vision
• Specific ministry purpose and calling where eDOT might partner
• The problem (funnel point) that eDOT might be able to solve
• How they’re solving the problem now
• Why that solution is insufficient
• What we’re proposing as a replacement/improvement

Result: A document that defines the above. This document is the beginning of Project Info Analysis and is delivered at Milestone #1.

Responsible	Accountable	Consulted	Informed
Owner	Partner	UI/UX

We’re not in the business of reinventing the wheel or competing with other ministries. If someone else already has a suitable solution, then advise the partner of that solution and show them how it solves their problem.
Result: Research findings added to Project Research Analysis.

Responsible	Accountable	Consulted	Informed
eDOT	Owner	UI/UX Dev SME

Put the proposal through the eDOT Project Evaluation Grid.
At this point, depending on the analysis of this grid, this project will proceed, be put on hold, or abandoned.
Score:
Result: A yes/no/hold vote from eDOT. Added to Project Research Analysis.

Responsible	Accountable	Consulted	Informed
Owner	eDOT	SME

A more detailed document defining the desired outcome.
Result: A signed document establishing who’s going to do what and outline the problems that will be solved.

Responsible	Accountable	Consulted	Informed
Owner	eDOT	UI/UX Dev

All stakeholders approve the research findings of the steps to this point.
Result: A yes/no/hold vote to proceed with the Project.

Responsible	Accountable	Consulted	Informed
Stakes	Owner

Identify the different types of people that have the problem you’re trying to solve. Personas are based on our understanding of the problem and not on our plan for the solution. Personas become the measuring stick by which all ideas are considered.
Create a character for each of these users. Include name, age, title/role, and even a sketch or stock photo for each person.
Result: A description of each persona that describes why, where, when, how, and how often that person will use the Product.

Responsible	Accountable	Consulted	Informed
Owner UI/UX	Owner

A bull-pen-style, all-hands-on-deck meeting to discuss the Project in general terms and then begin discussing the particulars
Result: A general understanding of what the problems are and how the Product will solve them. Hopefully, everyone on the team will catch the vision for the purpose and importance of the Product.

Responsible	Accountable	Consulted	Informed
UI/UX Dev GD Owner	Owner

Write informal, natural language descriptions of the Product features written from the perspective of the Personas. These stories can be written by anyone and they are written throughout the development process.
Format:
As [persona], [I need to / I want to] [something] so that [result].
Result: An informal, natural language description of each Product feature written from the perspective of a Persona.

Responsible	Accountable	Consulted	Informed
Owner	UI/UX	UI/UX

Flowchart/diagram how the user will use every feature of the app. Examples here.
Result: A flowchart or diagram showing how each feature fits in the larger Product.

Responsible	Accountable	Consulted	Informed
UI/UX	Owner	Dev

Identify the information the user might be hoping to find in or provide to the app and diagram how they are going to find/provide that information.
Systems that should be included if implemented: Labeling, Navigation, Search, and Internationalization & Localization.
More about Information Architecture.
Result: A plan for how the information in the Product will be structured. How this is presented depends on the architect and the Product.

Responsible	Accountable	Consulted	Informed
UI/UX	Owner	Dev

Create quick and rough sketches to capture your vision for the app. There are many methods for creating these including: white board, pen and paper, index cards, and prototype apps created for this purpose. The result should function as a storyboard for the Product.
Be sure to consider and apply recent trends and/or fads in app design. Always be on the lookout for features in other apps that you want to emulate. We call these features in the wild. Reference these apps and features in your wireframes.
Take pictures of everything and assemble them in such a way that you can use them as a storyboard to talk through how the app will function.
Share this story with others to build consensus that these features are on track to solve the problems.
Result: The ability to walk someone through the intended use of the app. Function takes priority over appearance.

Responsible	Accountable	Consulted	Informed
UI/UX	Owner	Dev

Identify the features that are absolutely required for the app to be useful. These would make up the Minimum Viable Product (MVP) and the Red Routes through the Product.
For example, in a dashboard GPS device red routes would include finding a location, finding the best route to get there, and guiding with step-by-step instructions. However, saving your home location, while useful, is not absolutely expected to exist for the device to be useful. “You want it when?”
More about Red Routes.
Result: A priority plan that orders the sequence of features as they will be developed.

Responsible	Accountable	Consulted	Informed
Dev	Owner	UI/UX

All stakeholders review and approve the items created by the steps since Milestone #1.
Result: A yes/no/hold vote to continue with the Project.

Responsible	Accountable	Consulted	Informed
Stakes	Owner

Create an artistic collage that attempts to illustrate the feelings they hope this app will invoke. This should capture they’re corporate/organizational look and feel as well as aspects of the culture they’re trying to reach.
This is a very subjective assignment, but very useful. If the Partner already has corporate branding that they want applied, then that might be enough to complete this step.
From this moodboard, you’ll hope to identify the app’s color palette, font styles, and even elements of the design (i.e. rounded corners vs blocked corners) and other touches that translate their style into the app.
More about Moodboards.
Result: The Moodboard delivered to the UI/UX Designer.

Responsible	Accountable	Consulted	Informed
Owner SME	Partner	UI/UX GD	UI/UX

Document the rules you adopt for how to properly design for this project. Adopt an established framework (such as Google’s Material Design), identify the development framework (currently Ionic), then document where you need to divert from these standards.
Document with the assumption that someone else will design updates and new features for the app. Make sure they can design in such a way that the flow and continuity of the new feature(s) flows seamlessly.
This document will include Color Schemes, Typography, Graphics, Icons, Transitions and Animations.
Note: This is a living document throughout the design process. It really won’t be complete until the end of the process.
Result: A detailed document describing the rules and standards that will guide the creation of the High-Fidelity Wireframes.

Responsible	Accountable	Consulted	Informed
UI/UX	Owner	GD Dev

Identify the individual, stand-alone tasks required to complete the Product. Then order them according to how they should be developed following the Red Routes first and then the rest of the Tasks in a logical order, always thinking about the Minimum Viable Product (MVP) and trying to keep the Product viable at every step of the iterative Development Cycle.
Result: All the features separated into manageable tasks as they will be pursued by development.

Responsible	Accountable	Consulted	Informed
Dev	Owner	UI/UX

For each Task that affects the User Interface, flesh out the wireframes using a tool that allows the developer to see your color choices and spacing. Right now, the preferred tool is Adobe XD.
These wireframes should also function as an early prototype.
They should be a close mockup of the final product as you have envisioned it. What the developers can and do achieve might be significantly different.
Be sure to include the any relevant Empty States, Waiting Times, & Error Messages.
Result: High-quality images that define the front-end user interface for each Task as they should be developed.

Responsible	Accountable	Consulted	Informed
UI/UX	Owner	Dev GD

The process of giving people your product and watching them use it. Is it intuitive? Does it work?
Interview the tester for their opinions with a pre-written questionnaire.
Repeat with as many of the target audience (personas) as possible.
Gather data into a report and discuss with partner ministry.
Result: Evidence that the Task as designed is intuitive to the user.

Responsible	Accountable	Consulted	Informed
UI/UX	Owner	Dev

Get approval for the designs.
Deliver to the developers.
Result: Images ready for the front-end developer to implement.

Responsible	Accountable	Consulted	Informed
UI/UX	Owner	GD Dev

All stakeholders review and approve the items created by the steps since Milestone #2.
Result: A yes/no/hold vote to continue with the Project.

Responsible	Accountable	Consulted	Informed
Stakes	Owner

The processes of creating the Product as designed above. The details of this process are outlined elsewhere.
Result: Implementation of a Task in the larger Project and eventually a publishable Product.

Responsible	Accountable	Consulted	Informed
Dev GD	UI/UX	Owner

• Dev – The Developer who writes the code according to the Design that becomes the final Product of this process. For the purposes of this document, this is a generic term that includes a variety of roles defined in another document. This would include all architects, programmers, and testers.
• eDOT – The parent ministry to KITT. This role represents eDOT’s management and general oversite of KITT’s projects. They will be informed of major milestones. A stake holder.
• GD – The Graphic Designer with various skill sets that will assist the UI/UX Designer with the look and feel of the final product.
• Owner – The Product Owner assigned to represent the Partner in the design and development process.
• Partner – eDOT’s Ministry Partner. The person or people that represent the ministry. They will work directly with the Product Owner to define and approve the Project. Rarely will the Partner work with the Developer. A stake holder.
• SME – Subject Matter Expert. Most of the time this role is implied and it is assumed that advise and input from SME’s will be sought whenever needed.
• Stakes – The Stakeholders represent the larger entities involved in the Project who have invested in the success of the Product. Both eDOT and the Partner are typically Stakeholders, however others might be included, such as eDOT’s parent ministry: Greater Europe Mission.
• UI/UX – The UI/UX Designer who works with the Product Owner, Graphic Designer, and Developer to define what the Project should look like and how it should function.

• Milestone – Significant points in the project where stake holders should approve of the progress to that point.
• Product – The result of the project when it is complete.
• Project – Generic for the whole task as it is being defined through this checklist.

• PDF – The PDF version of the information above.