The ITP help page supports 200+ students of NYU Tisch-ITP. This project is where I started incorporating accessibility in my UX practice. It has sparked my curiosity for inclusive design, and helped me gain subject matter expertise on WCAG 2.0 Web Accessibility standards.
Web accessibility simply means “an inclusive practice of ensuring there are no barriers that prevent access to websites by people of all types of abilities.” You can read more about WCAG or Web Content Accessibility Guidelines here.
I broke down a quick overview on how we tackled the project in the first 12 weeks, where our team went from learning about WCAG, redesigning for accessibility and teaching content managers how to be inclusive in their content creation process.
Week 1–3: How do you make websites accessible?
Before we can revamp the site to meet WCAG standards, there were many requirements to consider:
The site is hosted on Google Sites. We have consulted Web Accessibility experts and they recommend that we migrate the hosting from Google to WordPress, as the site has plenty of options with accessibility features.
User Experience is integral to prior to content migration, so instead of auditing for accessibility, we had to take a step back and redesign the IA of the site first.
Identifying managers of the site helped shape the initial redesign of the navigation, understanding which sites are deprecated, so we only carry over only what is relevant and useable content.
During my preliminary user interviews, I have heard many origin stories, some quick glances to how certain pages came about, (ITP is turning 40 this year!) and helpful insights from both admin users and the students.
What I’ve been hearing from the administrator’s side:
“We built this page so our e-mails to students would somehow live in a landing page.”
“The pages were born out of student’s needs and then it became unwieldy, or obsolete as most communications happen in the e-mails.”
“My workflow relies heavily on recreating last year’s pages, and keeping old recent versions accessible for reuse.”
What the students say:
“Iconography would help a lot in easily identifying content.”
“I would search Office Hours by google-ing. It’s faster that way.”
The team started with a simple survey to understand usage of the site.
I have created a pre- web redesign survey to identify features that would need focus in the redesign and the student questionnaire results.
Overview of results:
Week 4: Designing for Digital Accessibility: Teach Access Tutorial
At this point, the team was able to attend an hour workshop to understand the basics of digital accessibility. Teach Access has a good basic tutorial on building accessible sites.
Does the video have captioning? Google slides have a setting that can translate a presentation into captions.
How does one compose a standard alternate text?
Instead of hiding information, make sure all important and major information is displayed vs using accordions.
More of the accessibility quick win checklist here.
Week 5: A quick overview of the site map.
Using the current site map, the following were the steps we took:
Pull the current sitemap and do initial card sorting and design studio.
Review with stakeholders. Iterate based on feedback.
Create first wireframe and clickable prototype.
Week 6–7: Navigation redesign based on user roles
Our team spent 2 weeks to identify and rearchitect sections and pages in order of importance based on the initial survey we have done.
One of the challenges that we have encountered is that there were plenty of deprecated sites that need to be re-validated with Content Managers. For the first redesign, we wanted to simplify and do a cleanup of content and categorize the navigation considering not just the students need, but also content managers who are using the help site as a landing page to send out critical information to students.
The site is over a decade old and was managed by 3 content managers:
admin in charge of Registration
admin in charge of floor operations
editor that updates the event page
Week 8–9: Theming, styling, and identifying a scalable workflow
Selecting WordPress as a platform helped us expedite the web development side and focused on design and reorganizing content. We focused on Office Hours page as it is one of the most frequently used feature of the site. The page was redesigned and converted into custom HTML/CSS tables. We started working on setting up a child theme and translated the wireframe design into a proper homepage complete with hierarchy 3 sidebar.
While I had started adding content under the main page “Registration”, we started noticing some issues:
Content is very text-heavy eg. First Year Registration page, with both first year students in the team, Mark and Karina doesn’t recall benefitting from the content as they were going through registration. They recommended that the content could be cut shorter.
Labels needing a revamp. Some page titles are either too long, or are not very clear.
Creating a mobile-responsive version is part of first release.
Is hierarchy 3 (sidebar navigation) even necessary? We will have to validate this through user testing. We later found out that limiting the hierarchy to two levels is the most scalable design solution.
Week 10–12: Empowering Content Managers
The team has curated a list of guidelines that we will turnover to the content managers so new content created are being maintained following standards.
Frontier Health is an early stage startup that has an online global marketplace. FH connects MedTech innovators to over 200 Healthcare providers in Sub-saharan Africa.
Our goal is to develop a seamless on-boarding experience that features the business value proposition to increase user acquisition on the supply side of the business (Medtech device innovators).
Project Role: User Flow Map, Wireframe Sketches, Prototype
Duration: 1.5 months
UX Team Members: Ahad Basravi, Ariella Chivil, Riri Nagao, Krizia Fernando
Version 1: Automated Onboarding Process
The team got together within the first week to understand the service touch points of Frontier Health. How does the user first interact with the product/service and where does it begin and end?
Initially we were looking at existing marketplace B2B products that both service supply and demand, such as Airbnb and Ebay. The automated process of onboarding is our first user flow on how FH will be interacting with customers online.
Combining both the business requirements information we have collected after interviewing stakeholders, we started with whiteboard sketches to map out main features on the site, and have generated our first wireframe.
In the process of refining the messaging of the site, we have researched how popular business landing pages communicate to their customer. One perfect example is Uber, which has a very straightforward and simple copywriting.
Refining the persona through continued testing
Our user interviews revealed two types of users: (1) our early stage med-tech startup CEO and (2) an operations lead for a later stage startup.
Version 2: An Authentic/High Touch Approach
From our first design review with the Product Manager and the client, we have gathered different types of feedback which were very insightful and have contributed to the final redesign of the prototype.
What we learned:
Overall tone feels too simple; “Can they work with complex, clinical devices like mine?
“Markers of legitimacy” on landing page are important
Easy to understand at high level, but needs specific details; “How does it actually work?”
Would only commit to phone call after; “How small is this operation? Can they ship volume?