eDOT’s UI/UX Design Process
Here is the process eDOT follows to design the projects we choose to pursue.
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.
- 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.
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 ofProject Info Analysis and is delivered at Milestone #1.
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.
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.
Result: A yes/no/hold vote from eDOT. Added to Project Research Analysis.
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.
All stakeholders approve the research findings of the steps to this point.
Result: A yes/no/hold vote to proceed with the Project.
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.
A bullpen 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.
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.
More about User Stories.
Result: An informal, natural language description of each Product feature written from the perspective of a Persona.
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.
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.
More about Red Routes.
Result: A priority plan that orders the sequence of features as they will be developed.
Identify the information the user might be hoping to find in the app and diagram how they are going to find that information.
Systems that should be included if implemented: Labeling, Navigation, and Search.
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.
Create quick and rough sketches to capture your vision for the app. There are many methods for creating these including whiteboard, 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.
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.
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 to be 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
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.
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.
Begin Iterative Design Cycle with Development
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 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.
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.
Get approval for the designs.
Deliver to the developers.
Result: Images ready for the front-end developer to implement.
End Iterative Design Cycle
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.
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.