Skip to main content

After months—or years—of research, development, stakeholder feedback, and revisions, your toolkit is finally live.

The website works. The resources are available. The launch announcement has gone out.

Now what?

For university research teams developing digital toolkits, training resources, and other online tools, launch day is an important milestone. But it isn’t the end of the project.

A successful launch makes your work available. What happens afterward determines whether people can actually use it.

People Don’t Always Use a Toolkit the Way You Expect

During development, your team probably spent a lot of time thinking about who would use the toolkit and what they would need from it.

But once it’s available to the public, people bring their own goals, expectations, and circumstances.

They might arrive on a different page than you anticipated. They might skip the introduction and head straight for a downloadable resource. They might use a phone instead of a desktop computer, or need to complete a training module in several short sessions.

Some will encounter terminology they don’t understand. Others will have questions your team never thought to ask.

That’s not necessarily a problem with the toolkit. It’s an opportunity to learn how people interact with it outside the research environment.

Even basic information about which resources people access, where they enter the site, and where they leave can help your team make informed decisions about what to improve.

Accessibility Needs Attention After Launch, Too

Accessibility isn’t something you can check off once and forget.

Even if your toolkit was designed and tested for accessibility before launch, things change.

Someone uploads a new PDF. A training video gets replaced. A team member edits instructions or adds a new interactive feature. A software update changes how something behaves.

Each change introduces the possibility of a new accessibility barrier.

And some barriers only become apparent when people begin using the toolkit in ways your team didn’t anticipate.

A sustainable approach doesn’t require a complete accessibility audit every time someone changes a sentence. It does require clear expectations about how content is created, reviewed, and maintained.

The goal is to make accessibility part of the toolkit’s normal operation, rather than a problem someone has to fix later.

Who Owns the Toolkit Now?

This may be the most important question to answer before a project wraps up.

During development, responsibilities are usually clear. Researchers make content decisions. Developers build the technology. Project staff coordinate reviews and revisions.

But what happens when the development contract ends, the research assistant moves on, or the grant funding runs out?

Who updates outdated resources? Who responds when someone reports a broken link? Who makes sure the software continues working? Who knows how to publish a new resource without introducing accessibility problems?

Without a maintenance plan, even a well-designed toolkit can gradually become less useful.

That plan doesn’t have to be complicated. It might identify a responsible person or department, establish a schedule for reviewing content, and document how to handle technical problems and accessibility concerns.

The important thing is that someone knows what needs to happen—and has the information and resources to do it.

Your Toolkit Can Keep Teaching You

A digital toolkit isn’t just a way to share research findings. It can also provide information about how those findings are being used.

Website analytics can show which resources attract attention, which pages people visit most often, and whether users are accessing the toolkit primarily on mobile devices.

Feedback forms, interviews, and usability testing can help explain what those numbers mean.

For example, a resource that receives very few visits might be difficult to find, poorly labeled, or simply less relevant to your audience than expected. Analytics alone won’t tell you which explanation is correct.

But they can help you identify questions worth investigating.

This information can be valuable for improving the toolkit, documenting project outcomes, and informing future research or funding proposals.

Plan for the Next Version, Even if There Isn’t One Yet

Not every research project has funding for ongoing development. And not every toolkit needs a steady stream of new features.

Sometimes the right plan is simply to keep existing resources accurate, accessible, and available.

Other times, feedback reveals opportunities for a second phase: additional training materials, new audiences, translations, or features that weren’t feasible during the original project.

Either way, documenting what you’ve learned gives your team a better starting point if the opportunity arises.

It also helps preserve institutional knowledge when project staff change.

Build for Life After Launch

The best time to think about a toolkit’s future is before it launches.

That means asking a few practical questions during development:

  • Who will be responsible for maintaining the toolkit?
  • How will the team identify and address accessibility issues?
  • What information will help us understand whether people are using the resources?
  • How will content updates be made and reviewed?
  • What documentation will the next person need?

You don’t need an elaborate long-term technology strategy to answer these questions. You need a realistic plan that fits your team’s capacity and resources.

Because the real measure of a research toolkit isn’t simply whether it launches successfully.

It’s whether the people it was designed to serve can continue to find it, access it, and use it long after launch day.

Planning a research toolkit or wondering how to maintain one after launch? Tamarin Software helps university research teams build accessible digital resources designed for long-term use.

Ann CB Landis, CPACC

Ann CB Landis, CPACC, is the founder of Tamarin Software, where she helps university research teams and mission-driven organizations turn complex ideas into accessible, engaging digital tools, training, and resources. Her work combines software development, accessibility, communications, and systems thinking to create digital experiences that are useful, inclusive, and built to last. She also provides ADA Title II and WCAG accessibility consulting for public-facing organizations. Outside of work, Ann writes fiction, keeps honey bees, and remains fascinated by the intelligence of healthy systems—digital, natural, and human.

Leave a Reply