Design decisions need to be informed by survey responses, interview notes, and field observations. Wherever possible, responses should be categorized and graphed. The Domain Team needs to see what the actual users are saying and feeling. This will reduce Domain Team members' inclination to "go with their gut." They may not know their users as well as they think they know them. By providing data, UX designers can help teams focus on the users and make more objective decisions.

"Build or Buy?" is a question that often arises in UX, and both options should be considered. Much of the work done at BYU is not unique, and there are vendors who specialize in apps that are already built and tested. Oftentimes, the choice to buy is less expensive and leverages the specialized knowledge that a vendor must develop in order to stay in business. If the best option is to build, the deliverables should be clearly listed with explanations of their use cases.

Once the list of deliverables is made, the engineers should be consulted. They can give feedback on what can and cannot be done and the cost of creating the feature. Because the engineers will likely want to do their own research, they might delay giving the UX designer a response. Collaboration between engineers and designers is important; it can result in the development of estimates to help product owners prioritize their deliverable wish list.

Paper prototyping is an effective, inexpensive, and quick way to begin the design process. Designers may misunderstand the verbal descriptions given by owners, users, and other stakeholders. When designers create hand-drawn interpretations of the gathered requirements, users and stakeholders are able to see what the designer is envisioning. They are also given the opportunity to confirm or reject the design decisions. Paper prototyping allows your team to "fail fast and fail cheap" by highlighting what needs have not been met in the early stages of the design—and because it is easier to abandon the paper iteration and try again. Stakeholders enjoy paper prototyping because it allows them to see that their input is valued.

Users are able to understand the flow of an app with paper representations of screens. It doesn't take long for problems to be identified. A tangible representation of the workflow and design makes it easy for users to spot the things that confuse or frustrate them. They are usually happy to explain what doesn't work for them and why. This early-stage feedback can be used to revise the designs before engineers start to work.

Once the needs and wishes of the users have been consulted it is important to get the engineers' feedback on the design on whether it is feasible and how long it will take to build.

Ideally, the Domain Team will recognize the value of user feedback (gathered via thorough research and testing) and accept the design that incorporates that feedback. Ultimately, the project owner is responsible for signing off on the design points. Formally acknowledging their right to do so helps with keeping projects on time, within scope, and on budget. In the Agile process, the project owner must be available to make these types of final decisions on a regular basis.

Remember, the key is to make hand-drawn screens that represent the workflow of the app. It may take creating several versions of the paper prototype to discover what works best, but that time is well spent if it prevents future expensive changes and/or design failures. User feedback should convince the project owner to approve design decisions based on data, not a "gut" feeling.

The high-fidelity prototype, or the User Interface (UI), focuses on the design, branding, accessibility, and flow of the app. The paper prototyping process should have focused on the flow without concern for font, color, or styling. The paper prototype should inform the high-fidelity design based on testing and data. This is not an opportunity to start over. Most of the flow and usability decisions should have already been made.

The Office of IT UX Team has the tools and skills to create high-fidelity prototypes, which can and should be used for more user testing and for obtaining stakeholder approval. We use Adobe's XD (Experience Design) software, which is interactive and demonstrates the flow of the application.

It may be appropriate to create multiple iterations of high-fidelity prototypes. Adapting the design at this stage is still easier than it would be in the engineering phase (later on in the process).

Though it's tempting to move along with the development process, it's best to get formal approval of the design by the owner before coding starts. Proper communication will keep frustration levels low and save money. If the team's preference is to implement Agile techniques, then the owner should approve small increments in quick succession.

Once the design has been approved, the UX designer can provide design specifications to the engineers. Knowing the exact color, font, placement, and other specifications will make the engineers' job easier.

Engineers will build the product as requested and consult with the project manager while development constraints become apparent and force them to revise. It is critical that the engineers respect the user experience research, testing, and design process. It is highly probable that the engineers will need to make changes during the development process. Those recommendations for change must be shared with and approved by the project manager and project owner.

User experience extends beyond the release of a product, so it is important that the project team prepares for post-release needs. The project manager, in consultation with engineers and based on user-testing data, will prepare help documentation. Collaboration with The Office of IT Service Desk is invaluable in preparing for the release. The Service Desk employees will be better prepared to answer questions if they have good knowledge based on articles (KBs) and advanced notice.

Goals for the project should have been refined in the Research and Analyze stages. Product owners and domain teams should have agreed on deliverables beforehand. If those deliverables were clearly defined up front, it will be easier to know if the project is "done."

Testing with personas is critical to knowing if all user groups have their needs met. The Service Desk is a good resource for testing personas because they can anticipate the needs of their customers. Past testing has shown that the Service Desk employees are good representatives of all campus departments' needs. Though they are more tech-savvy than the average student, they make great alpha testers. Testing with real, average, random users is essential prior to release. It only takes 10 or 20 testers to find bugs and it is better to find those bugs before the release of your product than after. The UX Team is available to help with this testing.

As always, be prepared to make changes based on project goals, testing data, and the approval of the product owner. The product owner is responsible for prioritization.

Share the testing data and ask for the project owner's formal, written approval for the release. Notify the correct people throughout the change process. The inclusion of the Service Desk in testing ensures that no one is surprised by changes and that the information about the product is consistent.

Be prepared to test after release. It's a good idea to do a soft/quiet release at non-peak times so that a small group of testers can validate the site. Sometimes running two sites in parallel helps. In any case, go out quickly and talk to users across campus. 10 to 20 users will likely identify any pain points that could be fixed in the next release.