Improving the usability of the IT Help website at NYCHA

Achieved ~47% improvement in learnability for new users with Figma prototype compared to existing website.
Time to read: 7 min
No matter where you work, you most likely rely on a computer and a keyboard to get things done. Getting your work done means accessing Microsoft Office easily, or at least good internet connection. But what happens when you face a IT issue, like your computer breaks down? Ideally, you find the solution online or in a helpful workplace guide and you're up and running again in a few minutes. Or perhaps you file an IT ticket and get support quickly.

As a UX research fellow at NYCHA, I found what caused employees to get stuck and frustrated with resolving IT issues. Post-exploratory study, I designed a prototype on Figma that led to a 47% improvement in ease of learning for new users and 33% in ease of use compared to the existing IT website. With these findings, I created and taught a human-centered design workshop to executive and managerial staff.


Survey results from the baseline website measured against the Figma prototype that I designed based on user feedback.

The Challenge

At the NYC Housing Authority, IT support employees process 9.2k tickets per month. Yet with an increased need for digital devices and business software, IT issues are bound to increase.  IT support is an often overlooked yet crucial part of every business. This is especially true for a 90-year-old government agency with over 12,000 employees that is seeking to embrace technology on all fronts: hardware, software, and the processes that come with managing both.

Without an intuitive and useful workflow for resolving IT issues, employees may feel frustrated, stuck, and unable to complete their tasks. These tasks make up the work that serves the 300,000+ tenants who live in NYCHA’s public housing developments. How were employees resolving their IT issues? What did their workflow look like? Knowing this, how could we improve the usability of the IT Help website?

This is one of the participant's workflows in solving a hypothetical situation at NYCHA.
A workflow of how an employee resolves an IT issue: first tries by herself, then asks other, then creates a ticket online

I answered questions like these during my 12-week fellowship at the NYCHA. As the sole UX Researcher in the agency, I had the autonomy to define the research goals, select the most suitable methods, and lead interviewing, analysis, and prototyping. Together with my non-research managers and CIO, we determined the most impactful deliverables for long-term business goals.

✨ My internship was supported by the Siegel Public Interest Technology (PiTech) Fellowship from Cornell Tech.

Autonomously conducting end-to-end research

Being the sole UX research fellow at NYCHA was an incredibly valuable learning experience for me as it gave me the autonomy to plan and conduct research, while seeking buy-in from non-researchers who were working with me.

At NYCHA, my end-to-end research responsbilities meant drafting the research questions and plan, coordinating consent and schedules, all interviewing components (piloting, conducting, analysis), creating the scenarios for usability testing, and drafting a usability survey. I worked in a cross-functional team where my managers were not researchers, but rather executive employees for IT management. I focused on gathering buy-in and seeking feedback throughout the research process, such as including them in pilot interviews and affinity diagramming sessions.

Research questions

Users define the problem

Many felt IT seemed unreliable and unresponsible

IT issues were often critical, disruptive, and frustrating, but participants didn't always trust that IT would be helpful or responsive.

Confusing and overwhelming

Many participants were confused by the number of options and unintuitive layout of the website.

"I just call Bob from IT"

Participants were often relying on roundabout methods to resolve their IT issues, such as dialing a friend in the IT department.

The Research Process

Phase one: understanding current workflows and usability testing

Understanding the IT goals of NYCHA, in particular, was the initial challenge. First, I began by defining requirements with key stakeholders: the CIO, the Director of IT Processes, and the Senior Advisor to the CIO. With this in mind, I created the research goals and drafted a two-phase research plan. I made sure early on to communicate my goals to my non-research managers (IT Processes Director, Senior Advisor) by clearly explaining the research plan.

I decided to begin with an exploratory interview paired with a usability test of the existing website (”Service Portal”). Since I wanted to discover participants’ current workflows, I thought that grounding the interview in the Service Portal would help participants remember and elaborate on their experiences. This worked well as most participants had seen some but not all of the Service Portal.

Quotes from users

Here’s what some of the users said their experience using the Service Portal.

If I'm having an IT issue, I don't want to have to fight the IT site as well.

You can submit a service ticket. But the only problem with that is -- maybe it's because I'm old school -- you don't really feel that something's going to happen. Like it's just going to be sent into the abyss, right?

Phase Two: Prototyping and User Feedback

Prototyping to understand possible design changes

In Phase One, I identified 19 usability recommendations based on participant data that could improve the IT ticketing experience (e.g., consistency in naming, increasing the findability of the site, and various design tweaks to improve usability). In a design session with one manager, we sketched out a variety of improvements that we wanted to see based on the proposed changes. Based on these changes, I created a low-fidelity demo on Figma. You can find the demo here.

I returned to the same set of participants and asked them for their feedback on this new set of prototypes. To be sure, a few participants disliked parts of the new prototype and found it to be “boring”, have “too many options”, and preferred the existing system. However, the overall feedback was mostly positive. This was supported by a follow-up survey I collected that measured the baseline with the old website against the prototype.

💭 Reflection

This was my first applied role for UX research and I was very ambitious! I had no research budget, no in-house UXR mentors, and only 10 weeks to complete a two-phase study. I moved at a breakneck pace, surprising even myself: I was up and interviewing within 3 weeks (compared to the four months it usually took me in academia).

The Results

The Research Impact

While my internship has concluded, I am staying in touch with my team to see the ongoing impact of my work here at NYCHA. Through user testing, exploratory interviews, and prototyping, I’ve created a set of improvements for the next iteration of the Service Portal. These improvements are all based on empirical evidence from speaking to end users. Future work could include conducting evaluative tests to measure UX improvements and KPIs.

My internship deliverables

  1. A set of 19 proposed changes to the IT Help website based on empirical data. I mapped by feasibility and UX Impact to drive future development.
  1. A set of design guidelines for creating new UI/UX at NYCHA constructed from the interviews and design activities.
  1. Using this project as a case study for a 2-hour Human-Centered Design workshop for IT employees at NYCHA.
  1. Creating a database of resources for conducting future UXR at NYCHA.


What I would've done differently

Missing Audio Recordings — As the participants were also NYCHA employees, I sought to protect their privacy to an even greater extent than usual to not negatively impact their jobs. However, I failed to consider the power imbalance between the main office and the field office employees. Perhaps due to my position as an unknown intern from the main office, the field employees didn’t consent to have their audio or video recorded. Thus, I had to take mostly handwritten notes. The final presentation had more of a focus on main office employees, whom I recorded and transcribed in full.

In the future, with more time (and wisdom from experience!), I would try to introduce myself to the participants in another context if possible. For example, drop by and offer my services as IT support. Then I would ensure that I could resolve any concerns from the participants. In addition, I would like to ensure that there is compensation for research participation.

Avoiding the Rabbit Hole — As an academically-trained researcher, I’m tempted to dig deep and explore every interesting nook and cranny of the data. For this project, I used Dovetail. When I analyze data, I tend to code descriptively and exhaustively. This helps illuminate every aspect of the data in granular detail, but it takes forever. I had to keep my eyes on the goals — what were the research questions? When should I stop coding and move onto higher level themes?

Between Phase One and Phase Two, the amount of time coding took decreased by over 50% because I decided to stick with higher level, pre-set codes. I also had a clearer idea of what I was looking for — results that would come across as clear and novel for a presentation, not findings for a 10+ page research paper.