Skip to main content


HOW TO CREATE A USER EXPERIENCE TEAM

This is a temporary page related to the Educause Conference and our Team's Presentation. The goal of this page is to help other IT Professionals in Higher Education create their own UX Team.

Culture

The most important factor in creating a successful User Experience (UX) team, is getting public support from the management of the IT office. If everyone in the organization understands that the top-down focus is on the experience of the end-user, this in turn creates validation and respect for the work of the UX team. UX must be a collaborative experience. The project manager, engineers, and customers must see the value in investing so much “up front” time to create a better final product. Having the ongoing support of IT leaders is essential in making this type of culture shift. Without it, stakeholders may feel that it is fine to just “design on the fly” or trust their own knowledge or perspective of the needs of the user.

Strategic Imperatives Graphic

At BYU, the current and previous upper management of IT has funded and supported the UX Team. They have made it clear that all development teams must work within a structured process that includes systematic user research, prototyping, and testing. The “Strategic Imperatives” of BYU’s Office of IT reflect a commitment to respect and have empathy for the end user. We openly declare our intention to treat people with the “Golden Rule,” which is essentially empathy, and solid UX. We want to facilitate the work of people across campus by making sure our technology and commitments are reliable and safe.

Forming a UX team can support important initiatives, such as:

Accessibility

  • Understand user needs and government regulations
  • Develop a university-wide standard (Example: WCAG Standards)
  • Create a style guide to enforce branding and accessibility
  • Create a design system to speed up prototyping.

Branding

  • Create and train to University Brand Guidelines
  • Create prototyping style guide to speed up prototyping
  • Provide centralized training on branding

Implementation

  • Conduct user-testing before release of new software
  • Prepare training materials before release
  • Market/announce to targeted user groups
  • Partner with campus-wide communication channels

The Team

We are only successful because we leverage the talent, relative economy, and availability of our student employees. We are blessed to have a large pool of really smart, hard-working, and professional student employees. We are passionate about creating a mutually beneficial arrangement. We get great employees, and they get “real” work, training, and mentorship. Our students can add “primary responsibility for….” significant project work. They do the research, design, writing, testing, and collaboration. These students usually do not have a full-time employee going with them to meet users or customers. Of course, we review their work, provide training, and coach them on interactions. BYU is located in a high-tech hub, so we compete with big tech companies for student labor. For this reason, we have to pay better than many campus jobs. We offer flexible schedules dictated by the student’s academic schedule as well as hybrid remote and in-office work. Interestingly, the students have indicated a strong preference for co-location and in-office work. After having worked remotely for over a year, they have opined that they are more efficient and find greater joy in their work when they are working in the same place. Wherever they are, our student employees (and our non-student employees) are amazing. They have a passion for the end user and a level of professionalism that enhances our team’s reputation.

The reality is that hiring student employees is exhausting. They stay with us 1 to 2 years. Sometimes less and rarely more. So, we are constantly hiring and training. Another issue that we run into is the need to transfer work. We are fortunate that our campus partners understand our institution’s focus on experiential learning, as such they are gracious as we swap our team members. Our hiring process, see below, works very well, and allows us to screen out those students who do not have the essential skills we are looking for. However, we still have to teach them Adobe XD, Lucid Chart, and most importantly, teach them our team’s culture and process’. We take solace in the fact that BYU has a strong commitment to “experiential learning” outside of the classroom. Many of our student employees are able to use their work on our team as credit for internship classes. However, the biggest factor is that we enjoy the mentorship. We care about our students, and we take pride in their growth and their job readiness upon graduation. Yes, we have had some awkward interactions with stakeholders and some fashion fails, but the benefits of hiring student employees are so great, that we can block out those memories!

Hiring

We have found that the best way to hire employees is to ask them to do a Design or Writing Challenge. This is especially helpful for hiring students because they do not have large portfolios or experience. We also specifically state in the job description that we accept any academic majors. Strong UX and Technical Writing candidates can come from many backgrounds. This is particularly true of UX as they may have learned the skills in Design Thinking, Industrial Design, Graphic Design, Marketing, Illustration, or any number of majors and courses that teach user-focused research and design. For UX, we typically give a link to a website that has significant “opportunity” for improvement. We ask for a redesign with specific formatting criteria. We suggest two hours or less and ask them to only “fix” the first screen. We ask the Designer to explain their design choices with the hope to hear of an understanding of UX in their explanation. Having all applicants redesign the same website creates a fair comparison of the applicant pool. For Technical Writers, we provide a large block of text and ask for an edit. We invite them to edit and format that block to create the best document possible. They also must provide an explanation for why they made certain choices. From this set of instructions, we see a wide range of technical skill, creativity, and user-focused decisions. It makes the decisions on who to hire pretty easy.

Collaboration

Working with stakeholders is the key factor in good project work. When we started the team, we encountered resistance from some IT employees who felt that they were good designers and had a historical knowledge of the product, user need, and current state. We also had some concern that UX work would take too long and cost too much. We have been fortunate in that although people were concerned, most allowed us to show what we could do. We were also fortunate that they allowed us to make mistakes as we created a team and policies from scratch. We are still iterating, but we are finding success.

educause-hero-image.jpg
I like to show this video “The ROI of UX” to employees, engineers, project managers, customers, and upper management. It clearly states the “why” of UX and most stakeholders can recall previous bad development experiences that the video describes. I also like to use the metaphor of a house blueprint. Nobody would want to turn their money over to a contractor who did not start by asking what was needed in the build. They would not feel confident without a blueprint. They definitely would be nervous to hand over money without a scope of work and estimate. Most people would fear the house not matching the needs and taste of the future owner. They would also fear cost overruns and perhaps a complete failure to deliver. UX functions as the blueprint stage.

Here is a comment from an Engineering Director, Dan Cunningham:

The work done by our UX team is vital to the rapid development capabilities of our engineering teams. In my mind, projects without UX vetting up front are non-starters. Developers are not users. They are good at development but putting prototypes in front of them that have been defined based on good business processes and user journeys only makes us faster. Cost is really a non-question. Can you afford to rewrite your UI every time you release it? Can you afford to support an app that you spent a year on only to have your usage be next to nothing months after release because the users have abandoned a horrible user experience? UX can no longer be considered an overhead or a tax. It's not a luxury, it's part of the development life cycle. When we release now, we want our users to be surprised and delighted, not surprised and disappointed, so we do UX.

What about agile?

Here is the short version of what we have learned from our experiences:
  1. UX promotes the discovery and documentation of requirements.
  2. Those requirements or stories should go into a backlog.
  3. The prototype is the embodiment of the requirements.
  4. Having that prototype allows the customer to experience the app.
  5. The prototype allows the Project Manager and Engineers to estimate the cost of the features.
  6. Knowing the requirements and the cost allows the customer to prioritize the work.
The reality is that the Project Manager and the Developers will break up the tasks into sprints and run the project with their own best practices. Having an approved and agreed upon prototype makes the deliverables and expectations very clear.

Details/Suggestions

  1. We have about 20 student employees and 4 non-student employees.
  2. Most people are working on two projects at a time so that they have something to do when they are waiting on other people.
  3. We use Adobe XD because it works really well. We can send the prototype link to stakeholders who do not have a license. They love to interact with the prototype.
  4. XD is part of the Creative Cloud license, so we are not paying extra.
  5. Many students have previously learned Illustrator and Photoshop so they can quickly learn XD.
  6. We do weekly team meetings where all team members take turns as the trainer. We cycle through a list of UX related topics to make sure everyone learns the core principles of the team.
  7. We encourage employees to get written permission to include their work in their portfolios.
  8. Participate in the project planning cycle. Make sure that UX work is factored into the budgets and timelines of projects.

Summary

Our experience with User Experience has been good. The UX Team, like any IT project, has iterated and evolved over time. That means that while we have made mistakes, we always strive to do better and to improve upon past mistakes. We started with separate UX researchers and Designers and found that it stunted work. We now have the Designer do the research too. We have found that the Tech Writers are incredibly popular as they lighten the burden of documentation from the Project Manager. We see real synergy when the UX Designer and Tech Writer partner on the project. They research together, collaborate on content and flow, and generally back each other up.

In the end, the question is, how have we improved the experience of the users? We talk to our Service Desk Managers. We read the content of the call logs to find out what is causing problems. We strive to fix those high-frequency problems. We check back with customers and end users. We look for metrics that show that we are improving the experience on campus.

We know that much of the interaction that students have at BYU is digital. We want everyone to feel that they are being helped and welcomed by the technology. We do not want to be a barrier to them feeling good about being a BYU student. In the BYU “Statement of Belonging” one of the goals is that “Our interactions create and support an environment of belonging.” The UX Team’s primary reason for existence is to improve those interactions and the BYU experience.


Peruse the rest of our website for additional information, resources, work examples, and more.

Explore the Site

Test

Test

Test Content Item

As a member of the UX Team, you will often write documentation that will likely only be seen by other employees at BYU’s Office of IT. Your style and voice should not change simply because you aren’t writing for a wide audience. Don’t overwhelm the reader with technical jargon without explanation just because they already work at OIT. Your writing should be clear, accessible, and formal no matter the audience.