The Basics

The Company:

Technovation is a nonprofit that runs a program called Technovation Girls, a technology and entrepreneurship competition where girls work in teams to build apps or AI projects that address a specific problem of their choosing. Along the way, girls are supported by a range of volunteers, including Ambassadors, Mentors, and Judges.

Note: I have been part of Technovation’s marketing team since 2013 and have seen many evolutions of the organization, program, and website. This revision had been necessary for a few years and I am proud to have finally pushed it through in 2024.

The Challenge:

Each audience type registers for the program in a different way, on separate platforms.

Additionally, on the existing page, information about each role (time commitment, responsibilities, qualifications) was squashed into a tiny tab-style module.

The team was compensating for this lack of information by creating slide decks, fliers, or FAQs, which created an extra lift for them and a confusing user journey for potential volunteers.

The Solution:

Working closely with the teams responsible for each audience type to understand their audiences’ needs and typical user journeys, I developed an improved information architecture that still offered a central landing page for people to review all participation opportunities, but also offered dedicated sub-pages for each participant type.

Interviews and Information:

I began by meeting with each team responsible for recruiting and managing the program experience for each of our core audiences: students (and their parents), Local program leaders (called Ambassadors), volunteer mentors, volunteer judges, and program alumnae (who often volunteer in local leadership roles).

I met with representatives from the Volunteer Engagement team, the Program team, our Corporate Engagement team, and our Fundraising Team, as well as soliciting feedback from the entire organization via a general user feedback survey.

I asked them about their experience with the current website, including questions like:

• Walk me through the recruitment process—what materials do you share with potential participants or volunteers? When do you share each material?

• Do you find yourself sharing slide decks or PDFs instead of the website? Why?

• What information or content would make the website a better resource for you, as someone managing participant/volunteer experiences, and what information/content would make the website a better resource for those audiences you serve?

• Do you have an ideal engagement process in mind for the audience you serve?

• What other pain points do you have with our website?

Analyzing User Feedback, Identifying patterns, and Outlining a Revised User Flow:

After interviewing everyone, I identified common pain points about the website generally, as well as for each team and their audience specifically. I organized this information into a simple table that kept the details clear and straightforward to act as a guiding tool during the entire project.

I then used that summary to create a revised Site Map that allowed for more tailored user journeys for each of our core audiences.

Mockups and Conversations:

I created a simple wireframe to have a starting point for discussions with other teams.

This is a mock-up of a revised version of the “Get Started Page.” A few key updates:

• Copy Adjustment: This page and menu item were renamed to “Get Involved” as several team members indicated that their target audiences were confused by the term “Get Started” assuming it would lead them right into the program and competition content.

• Structural edit: each audience type is now listed vertically to give adequate room for role descriptions and expectations.

• Structural edit: (not shown): Most audience types would also have an additional, separate, landing page built out for them. This way full information about what to expect from the program could be listed in its entirety for those who were interested, but there was still an immediate conversion on the main Get Involved landing page

• Look & Feel: We had recently refreshed our branding to use a more limited palette and had stronger voice and tone materials for each audience developed. I used these assets to bring the revised pages (and new pages) more in line with the updated branding.

Review and Revisions:

While the team members I shared this with were enthusiastic, I knew that there were some additional adjustments that would make the page stronger.

A few changes from mock-up to production to highlight:

• This initial mock-up included a proposed table comparing the different roles. I removed this in favor of a more streamlined 1-sentence summary of each role at the top of the page that contained an anchor link to the sub-section on the page.

  • The information made sense to have at the top of the page for people looking to quickly find the best fit for them

  • Much of the information planned for the table ultimately made sense to keep in a deeper sub-page.

• Inconsistent language conventions in describing roles: some had a simple name (“Girls”) while others described what you’d be doing (“Run the Program”). In the final design I made this consistent to avoid confusion.

Building it Out: processes, tools and platforms:

We were working on a WordPress site with a custom theme, and used Elementor to build the pages and create templatized blocks to make building sub-pages quicker and easier while also maintaining consistency in look and feel.

• This also allowed for quicker responses to team feedback — building templates as we built out the main landing page and first sub-page meant that adjustments to the other sub-pages that were in a different stage of the build process could be updated globally instead of individually.

Redirections: Because the site and program had undergone several iterations, there were existing pages that needed to be redirected. I created a plan mapping out which pages required redirections, where they would redirect, and what kind of redirection would be necessary. When the final pages had been approved, before pushing live, the redirections were set up using the redirection tool in WordPress. Checking the redirections on both the front-end and back-end were checks within each page’s QA process.

SEO and Metadata: Building and redesigning new pages was an opportunity to optimize for search, and SEO was a consideration from the start of the copywriting process through the production of each page in page architecture and media metadata. I also consulted Google Search Console and Moz to understand which terms people were using to arrive at our site, and identify potential opportunities. To provide the team with additional data, I also built out tracking links for each page to better determine in Google Analytics how people were moving through the site and arriving at our separate platform where they signed up.

QA: After content had been approved by teams, I built the pages out on our staging site and then shared for review with the team that “owned” the page being reviewed as well as 1-2 volunteers from other teams who could provide fresher eyes on both copy and functionality. Depending on who was reviewing, each person was given a checklist of things to check (for instance, people on other teams couldn’t check for accuracy of the content, but they could provide feedback on clarity). And because these pages functioned as part of a larger flow, people were also asked to review the ease of navigating between pages or finding specific pieces of information.