Skip to main content
Office of Information Technology
User Experience Team


BYU OIT USER EXPERIENCE DESIGN TEAM PROCESS

The UX Process checklist below defines best practices and certifications in user experience and is intended to be a resource for product and project teams. Domain teams can use this checklist to create a product that follows UX principles. The UX team is ready to research, prototype, test, and assist as needed.
Download the UX Process Checklist
Tab heading icon
Tab heading icon
Research
Tab heading icon
Tab heading icon
Analyze
Tab heading icon
Tab heading icon
UX Design
Tab heading icon
Tab heading icon
UI Design
Tab heading icon
Tab heading icon
Develop & Validate
Tab heading icon
Tab heading icon
Release
  • "You are not the user" is a common phrase in UX. Its purpose is to remind you—the designer—to consider the actual user needs involved in a project. You should take some time to identify who uses (or would use) your product. Are they students? Faculty? Staff? Members of a specific department?

    In his article “Understanding Stakeholders through Research,” Jim Ross wrote the following: "Stakeholder refers to a person who holds a stake, or has a vested interest in a project. Although the users of a product or service obviously have a stake in it, we usually use the term stakeholder to refer to key people in a company that is building a product. This often includes clients, managers, department heads, subject-matter experts—and sometimes, user representatives."
  • Personas are realistic representations of the users your product will serve. Each persona will have personality, needs, goals, and responsibilities that extend beyond the scope of the project, including family context, aspirations, or accessibility considerations.


    These representations help you understand how users may interact with the product and identify potential barriers. Personas may also reveal additional user groups that were not previously considered.


    View the OIT personas list
  • Personas are most effective when used in realistic scenarios. For example, a student may access a website from home or on their way to class. A parent using the site to assist a student may have different needs.


    Considering each scenario allows you to identify pitfalls and obstacles before users interact with the product.


    For more information on personas, please refer to our Research page.
  • Users are often willing to share their opinions and provide information about their needs. Collect this input through surveys, user testing, and interviews with relevant groups.

    In surveys and interviews, include open-ended questions to identify concerns and needs that may not have been previously considered.

    If your website is already live but requires revision, consider having users test the existing product to identify current pain points.
  • To evaluate the impact of your work, define metrics that demonstrate improvements in the user experience. Collect data both before and after implementing changes. Consider using experience mapping, surveys, and user observation, as well as tracking Service Desk requests related to your product and measuring maintenance costs and development effort.

    For more information on gathering metrics, please refer to our Resources page.
  • Design decisions should be guided by survey data, interview findings, and field observations. Wherever possible, responses should be categorized and graphed. Providing this data helps the Domain Team understand user needs and supports more objective decision-making. UX designers use this data to keep teams focused on users and outcomes.
  • “Build or buy?” is a common question in UX, and both options should be considered. Much of the work done at BYU is not unique, and vendors may offer solutions that are already developed and tested. In some cases, purchasing a solution is more cost-effective and leverages vendor expertise.

    If the best option is to build, the deliverables should be clearly listed with explanations of their intended use cases.
  • Once the list of deliverables has been created, engineers should be consulted. They can provide feedback on feasibility and estimated development effort. Engineers may need time to conduct their own research before providing feedback.

    Collaboration between engineers and designers supports the development of estimates that help product owners prioritize their deliverables effectively.
  • Paper prototyping is an efficient and cost-effective way to begin the design process. Designers may misinterpret verbal descriptions provided by stakeholders and users. Creating hand-drawn representations of requirements allows stakeholders and users to better understand proposed designs and provide feedback.

    Paper prototypes make it easier to identify unmet needs and support rapid iteration. Because changes can be made quickly and at low cost, teams can revise designs immediately after receiving stakeholder feedback. This process demonstrates that stakeholder input is considered and incorporated.
  • Paper representations allow users to understand the flow of an application and identify issues quickly. A tangible representation of workflow and design helps users identify areas of confusion or difficulty and provide specific feedback. This early-stage feedback can be used to revise designs before development begins.

    After gathering user input, engineers should be consulted to evaluate feasibility and estimate development effort.
  • The Domain Team should consider user feedback gathered through research and testing when evaluating design decisions. The project owner is responsible for final approval of the design. A clear understanding of this responsibility supports project timelines, scope, and budget. In the Agile process, the project owner must be available to make these decisions on a regular basis.
  • Focus on creating hand-drawn screens that represent the workflow of the application. Multiple iterations may be required to determine the best design. This process helps reduce the risk of costly revisions and design issues later.
    User feedback supports the data-driven design decisions and helps guide project owner approval.
  • The high-fidelity prototype, or user interface (UI), focuses on design, branding, accessibility, and overall flow. Earlier paper prototyping should establish the application flow without concern for font, color, or styling.

    The paper prototype should inform high-fidelity design decisions based on testing and data. At this stage, the focus is on refining and applying established decisions rather than redefining the overall flow and usability.
  • The Office of Information Technology UX Team has the tools and expertise to create high-fidelity prototypes, which are used for additional user testing and stakeholder approval. We use Figma, an interactive prototyping tool that demonstrates application flow.
  • Multiple iterations of high-fidelity prototypes may be necessary. Making design changes at this stage is still easier than during the engineering phase.
  • Before development begins, formal approval of the design should be obtained from the project owner. Clear communication helps maintain alignment and reduce the risk of costly revisions.

    In Agile environments, the project owner should approve design decisions in smaller increments on a regular basis.
  • Once the design has been approved, the UX designer can provide detailed design specifications to the engineers. Clear specifications for color, typography, layout, and other elements support efficient and accurate implementation.
  • Engineers build the product based on approved designs and collaborate with the project manager as development constraints are identified. Revisions may be necessary during the development process.

    Maintaining alignment with user experience research, testing, and design is essential. Any proposed changes should be reviewed and approved by the project manager and project owner.
  • User experience extends beyond product release, making it important to plan for post-release support. The project manager, in consultation with engineers and guided by user testing data, develops supporting documentation.

    Coordination with the Service Desk, including knowledge base (KB) articles and advance notice, ensures readiness to support users.
  • Project goals should be refined during the Research and Analyze stages. Product owners and Domain Teams should agree on deliverables early in the process. Clearly defined deliverables make it easier to determine when the project is complete.
  • Testing with personas is critical to ensuring the needs of all user groups are met. The Service Desk can provide valuable input due to their familiarity with user needs and common issues. Testing with office employees can also be helpful prior to release, as they represent different campus departments and their needs.

    Random, average users should also be used in usability prior to release. A small group of users is often sufficient to identify key usability issues. Identifying and addressing these issues before release helps reduce post-release defects.

    The UX Team can assist with planning and conducting user testing.
  • Be prepared to make changes based on project goals, testing data, and product owner approval. The product owner is responsible for prioritization.
  • Share testing data and obtain formal, written approval for the release from the project owner. Notify relevant stakeholders throughout the change process. Involving the Service Desk in testing helps ensure alignment and consistent communication about the product.
  • Continue testing after release to identify opportunities for improvement. A quiet release at non-peak time allows a small group of users to validate the product. In some cases, running parallel versions of the site may be appropriate.

    Early post-release testing with a small group of users across campus is often sufficient to identify key usability issues. Addressing these issues supports improvements in subsequent releases.