.png)
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?
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.
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.
IT issues were often critical, disruptive, and frustrating, but participants didn't always trust that IT would be helpful or responsive.
Many participants were confused by the number of options and unintuitive layout of the website.
Participants were often relying on roundabout methods to resolve their IT issues, such as dialing a friend in the IT department.
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.
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?
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.
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).
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.
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.
.png)
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.