As soon as I crossed the finish line at the NYRR Al Gordon Brooklyn 4M race, I went to Rise NYC to participate in the NYC OpenRecords UX Hackathon on Saturday, February 25th. We collaborated with the City on the OpenRecords platform to provide everyday New Yorkers access to government records, data and other information. Here is my full recap of the event and what I learned.
ABOUT
The event was organized by Michael Lapin of Beginex UX and Shannon Copfer Brace of The UX Lab NYC (also creator of the Empathy Jam) to bring together UX designers, researchers, developers, product people and everyone in between to improve their skills and make a meaningful contribution to the City.
The goal of the hackathon was to collaborate with the City to give New Yorkers access to information and empower them with the knowledge to stay informed and keep their governments accountable.
PRE-HACK
The first part of the day focused on introducing the OpenRecords platform and setting the context of our challenge. Pauline Toole, Commissioner of the Department of Records and Information Services (DORIS) kicked it off by introducing the history of DORIS.
It was established in 1977 and helps preserves and provides public access to historical and contemporary records and information about New York City government through the Municipal Archives, the Municipal Library, and the Visitor Center.
Next, Joel Castillo, NYC DORIS and OpenRecords’ Lead Developer introduced the platform and its features. He walked us through the process to submit a request and what users could expect. He also introduced the hackathon challenge along with Michael and Shannon and gave us three different approaches (more in detail below).
Afterwards, they opened up the floor for questions from participants. There were many, ranging from technical to the platform’s broader implications, which was a sign that we had an abundant amount of opportunities for redesigning OpenRecords’ features.
To help us with the research portion, Terry Constantino, Principal of Usability Matters presented an introductory workshop on usability testing. She went through the importance of testing, especially early in the process and how to do so effectively to get the feedback that is needed to influence the design.
THE CHALLENGE
The user group that we focused on was everyday New Yorkers. OpenRecords is mostly used by journalists and advocates who know what they are looking for but we decided to design for people who might stumble upon this and want to explore its capacities.
We were provided three potential approaches to the challenge:
1. Making a New Request
- How might we help a user get their request to the correct agency? This will require education about other agencies and what they can provide. (Often, they default to requesting from DORIS because they cannot tell there is another agency they should be asking).
- How might we improve the submission form and messaging while accounting for the different questions/information required by different agencies? Should users be notified that requests will be viewable by public?
- How might we make the form itself as simple and accessible as possible?
2. User Introduction/Guidance (Homepage)
- How might we help the user determine if they should be using OpenRecords for their request, or some other resource like the Open Data portal? In particular, we want to make sure users do not submit requests that a FOIL request would not help with (e.g. if the information they require is already in the Open Data portal, municipal archives, or public collections).
- How might we help the user know to search and view existing records prior to submitting a new request (to ensure they don’t submit a duplicate request)?
- How might we set expectations for what the OpenRecords tool does and how it communicates?
3. Search, View, Track Past Requested Records
- How might we help a user easily discover whether a similar records request has already been filled?
- How might we help the user make sure they search and view existing records first so they do not submit a duplicate request?
- How might we simplify the search and filtering of past records requests?
- How might we help a user check the status of a past request they made?
PROCESS
My teammates were Ariella Chivil, Jennifer Fragale and Rafael Caba. Our goal was to deliver a clickable prototype of a realistic solution that stays within legal limitations and technical constraints.
After a speed round of introductions, we settled on a game plan for the project workflow. We planned to do our research and have solutions sketched out at the halfway point. The second half would be dedicated for prototyping, iterating and practicing our presentation.
The hacking portion started from around 11:00am and our deadline to submit everything was 5:00pm sharp. We got down to business!
UX RESEARCH
What I love about UX hackathons is the focus on research and figuring out problems before jumping into solutions. Although the problems with OpenRecords were obvious, we did our research to collect data to be able to make solid design decisions.
Developing Assumptions
We weren’t sure of which challenge to do so we started out with quick usability testing. We wanted to know if users understand the purpose of the site and what they could use it for. More importantly, we wanted to see if they felt empowered with the availability of this platform and where the pain points are that may prevent them from feeling this way.
Here are our pre-interview assumptions:
- The site is confusing and doesn’t provide users with value.
- The landing page doesn’t align with the City’s goal of empowering New Yorkers with information to keep their governments accountable.
- Users don’t know what the Freedom of Information Law (FOIL) act is. They need context. They have no idea what they could request.
- The open-ended description box is overwhemling. They don’t know how much information to submit for it to be sufficient.
User Interviews & Usability Testing
To validate these assumptions, we rounded up four everyday New Yorkers and tested the site. We asked them:
- Tell me about the last time (or most memorable experience of when) you attempted to obtain a record? Walk me through the process. How did you feel?
- What does this front page tell you? What do you think is going on?
- Imagine you’re interested in learning more about environmental proposals and want to obtain correspondences from the Mayor. How would you go about it?
- How would you describe this platform to a friend?
During usability testing, users had the tendency to jump into their own solutions. For us, it was important to listen to and focus on their behaviors and past experiences. Another thing I learned was the value of silence. I like to fill up silence so it was tempting to insert questions when users didn’t have anything to expand on. To challenge myself, however, I paused longer than usual and let the user do the talking. The best insights we got were from those silence fillers!
Affinity Mapping
After speaking with users, we identified patterns in their pain points. We put the users’ feedback on post-it notes and mapped out our findings. We started to notice how common some of the problems were.
The feedback from our users validated the assumptions we developed and discovered additional pain points. Some of them include:
- The site didn’t feel welcoming. Users also didn’t feel like empowered customers.
- Submitting a request to one agency is extremely limiting and was a frustrating experience. If users categorize their requests based on their preconceived notions but finds out later that they go to a different agencies, it’ll be annoying.
- If something went wrong, there weren’t any messages to alleviate that emotional distress. When users hit a dead end, there wasn’t a clear next step.
- The extensive contact information form fields were overwhelming.
SKETCHING SOLUTIONS
This is where the fun began! UX design is a problem solving process so the exciting part was taking the research and coming up with solutions. We felt strongly that the user should feel empowered when they use this platform. Our priority was to take the guesswork out of identifying which agency users should be submitting their requests to. We decided to tackle challenge #1: making a new request.
Redesigning the User Flow
We started by rethinking the current flow. Since we’ve identified the pain points, we created a new flow that streamlines the process and makes it easier for users to stay engaged. Even if they hit a dead end, the design will pick the users up and direct them somewhere.
Obtaining Expert Advice
Once we figured out our flow, we had brief discussions with the on-site staff attorney, Dominic Mauro, as well as Peter, a developer from DORIS. In order to design a practical and useful solution, our prototype needed to consider the legal and technical limitations.
What was unexpected (but a pleasant surprise) was hearing how they would incorporate those technical and legal constraints into the design. It was the developer who suggested using a mad libs style form to make it easier for users.
In real life UX situations, it’s important to have the skill to communicate with the legal team and the developers. They’re essentially the UX designers’ best friends. It was great to get them involved early enough in design process and have them contribute to the solution.
Silent Sketching & Dot Voting
With a solid flow in mind, it was time to get sketching in silence. Silent sketching is an activity that is part of the design sprint process, invented by the designers at GV. I’ve incorporated this in numerous projects and it’s extremely effective in terms of getting the best ideas out on the table. So that’s what we did.
Since we were battling with time, Jennifer and I sketched digitally to create the skeleton for the prototype and Ariella and Rafael created physical sketches, focusing on the flow and the copy. We individually sketched for 30 minutes and put our tools down once the timer ran out.
Afterwards, we critiqued each other’s sketches through the “dot voting” method. Good design should speak for itself so rather than present our work out loud, we picked out features we liked with votes. This saved a lot of time and allowed us to highlight the best features of each design without having lengthy discussions about them.
We started out with a “Choose your own adventure” flow where users pick a general interest (such as environmental, real estate, business, etc.) and go from there. They would then be given a list of recommended documents and information that could be requested. Finally, this would direct them to the best matches of agencies.
PROTOTYPE & ITERATE
At this point, we were down to the last hour before everything was due. In order to make the most out of the remaining time, we strategically divided up the work so we could present a prototype that has been through at least one iteration. We used Ariella’s sketch, which had the most complete copy and covered the entire flow and tested it with users. At the same time, we started refining the digitized screens in Sketch.
Digitizing Wireframes & Prototyping
The goal with the prototype was to nail the concept and showcase the end-to-end interaction from landing on the page to submitting a FOIL request. With limited time, we focused on showcasing accurate copy and clear actionable steps on each screen.
There were moments when we got lost in the finer parts and trying to make them pixel-perfect. But as long as the interaction was obvious, we didn’t dwell too much. At minimum, we tried to build a mid-fidelity wireframe where the copy was complete and the clickable areas were obvious.
Usability Testing & Iteration
While Jennifer and I were working on refining the prototype, Ariella and Rafael took the wireframe sketches and tested them with three users. We asked them to perform a task – to request any records regarding environmental proposals related to Central Park from 2016. Here are some of the best feedback:
- The “Choose your own adventure” flow was way too cumbersome. Users wanted to get straight to the point.
- Users liked the option of searching with keywords and having a list of recommended agencies.
- It was helpful to users when they were able to see what others have requested in the past and which agency they went through.
- They felt more comfortable about exploring the potential of the platform.
- Users still needed more context on the information that is available.
- The mad libs inspired description field was highly popular.
FINAL WORK & PRESENTATION
Polishing the Prototype
With less than an hour on the clock, we diligently continued to refine and iterate on our prototype. As the feedback was coming in, the prototype was getting better. The criticism from the sketches were especially helpful and got us to wear our innovative hats and think hard about the potential solutions. Once we were content with most of the screens, we threw the screens in InVision to deliver a final, clickable prototype.
Presentation
Since this is a UX hackathon, we needed to ground our presentation on the research and explain how each decision was made on the basis of feedback and data. We shared our findings from the research and took everyone through the prototype step-by-step and explained the reasoning behind each decision. The best part? Ariella was a rock star and kept the presentation under three minutes, like a boss!
On the landing page, we kept the copy and branding identical to what it currently is. We took the “Translate” and expanded that to show New York City’s most commonly used languages (in their language) with the option of seeing more to translate the page. Accessibility in design is absolutely critical, especially when working with the public sector and we wanted to incorporate that.
As for the flow, users have the option of either choosing an interest or entering their own key words, a nice 2-in-1 option. Based on their key words, a list of previously submitted requests would show. If none of them match what the user wants, they’re taken to a page to submit their own FOIL request.
AWARDS CEREMONY
While the judges deliberated, we all received certificates signed by the Mayor for our participation. It was rewarding to receive recognition for making contributions towards helping the City improve the ways they communicate with its residents and preserving its history.
Finally, the moment we have been waiting for has arrived. It was time to announce the winners! In addition to the first place award, they had other categories and recognized teams who had the most complete prototype, best research and most innovative. My team proudly took home best presentation and I’m ecstatic about that. All the groups did a wonderful job and deserve a round of applause!
CONCLUSION
This event was structured and planned incredibly well. The hosts, mentors and experts made sure that we were on their timeline of completing each portion of the design process to get everything done in time. Every group did solid research, created a flow, sketched out solutions, wireframed and finalized a clickable prototype. In a nutshell: the UX of this UX hackathon was great.
I also liked how the challenge allowed me to work on a real product with real problems and know that parts of my design could potentially be incorporated into the next iteration of OpenRecords. I’m looking forward to seeing how DORIS improves this platform and more importantly, how they will continue to empower New Yorkers and increase transparency.
By the end of the day, I was exhausted. I started at 5:30am and traveled to Prospect Park to run a few miles and then traveled back into Manhattan to create a solution to help everyday New Yorkers access the City’s information and archives. Spending a full day doing two things that I really love (running and design) was rewarding. I can’t wait to see what challenge I get to work on next!
Cheers,
Riri
