Streamlining the sign up process for small businesses accessing trade support

Connecting small businesses with resources and expertise across industries to promote economic development and job creation


The current sign-up process for accessing events and supports from MEDJCT was tailored specifically to in-person events, and needed to be updated to reflect the changing landscape in a post-pandemic world.


Generate prototypes that simplify the sign-up experience for supports and events. Understand what information is valuable to users and provide high-value content to users as often as possible. Create recommendations for a remote-first event sign-up process that meets users needs.


Host feedback sessions with prototype designs that reflect business needs, and generate insights that can be built into the revised solutions. Modify prototype designs, test again.


Update prototype again and provide MEDJCT with informed, user-focused recommendations for the development of this service delivery. MEDJCT took our recommendations positively, and are currently developing new solutions to support businesses based on our insights from users.



When the world went into varying degrees of shutdown because of the COVID-19 pandemic, many things were disrupted. The way thinks worked simply was no longer effective, or in some cases even safe. Ontario's Ministry of Economic Development, Job Creation and Trade (MEDJCT) are one of many groups within the government doing their very best to create opportunities out of the chaos of the pandemic, and this project is about one of their efforts to do so.

At the Ontario Digital Service prototyping lab, we operate as a sort of internal consultancy for Ministries within the provincial government who need help tackling problems from an outside perspective. We were approached by MEDJCT for help regarding the sign-up process for events they were hosting to help small businesses navigate the changing business landscape. Obviously this is a topical issue, and we jumped right in.                        

A graphical representation of the timeline of work on this project. 1. Secondary research into problem space. 2: Host interviews with ministry partners. 3: Develop problem statement and interview framework. 4: Work with ministry partners to build prototype in Figma. 5: Lead feedback sessions with representatives from small businesses, and coach ministry partners. 6: Gather insights, make changes to prototype based on feedback. 7: Lead another set of feedback sessions with small business reps. 8: Gather insights to inform recommendations to ministry partners.
Figure 1.1: Project timeline

Over the course of the project, we conducted 2 rounds of quick, condensed user testing on prototypes developed in a small team. I was one of 3 staff members on this project. We built prototypes in Figma, generated open-ended research questions, hosted sessions with users and revised our prototypes based on their feedback. Once we tested again, we iterated once more to make informed recommendations to the ministry about the needs of the users when signing up for webinars and virtual trade missions online.


Business priorities

Simply put, our highest priority was to make accessing the resources available at webinars and trade events easy for businesses in Ontario. What that looked like in this context was a simple, fast, and easy-to-navigate sign-up form that clearly articulated the value for users in attending an event. We heard from our stakeholders that serving businesses effectively required extensive outreach with many types of potential users, and so off we went to get started on recruitment.

How might we make the resources available at webinars and trade events easy to access for businesses in Ontario? Further, how can we clearly communicate what value these events can bring to businesses who attend?

Testing with a diverse range of users              

Our aim for the project was to cast a wide net for user feedback, and try to balance common needs across scales of companies. We reached out to 7 different user groups, and hosted 12 feedback sessions: some private sector, small medium and large, and some public sector folks. We were able to reach a number of businesses who had no prior experience with the ministry and leveraged existing relationships to fill in gaps in our outreach.                


What I did specifically

Working with a small sub-set of the lab team, I had many hats on this project: I was responsible for some prototyping, leading some research, and writing good research questions to contribute to our feedback sessions. There are also many other activities that go into a project like this, including research operations and stakeholder relationship management. Ultimately the lab is a fast-moving, collaborative environment and each member of the team is responsible for a large amount of work to ensure things get done well.                


Stakeholder interviews                

We spoke to lots of folks from the MEDJCT to better understand what they hoped to learn from our research engagement. After multiple interviews, we had a good understanding of the problem space and decided it would be wise to test a coded prototype in the first round of our testing and a Figma-based prototype for the second round.

Our stakeholders on the immediate team attended many of the feedback sessions and worked with us to co-design the prototypes and solutions. Working collaboratively with non-designers can be challenging but our stakeholders were willing to put in the time to truly understand their users. This can only serve to benefit them moving forward.

Time-sensitive work                

As a result of the pandemic, the need for this product was higher than ever: we were asked to conduct all of our feedback sessions in the span of one (1!) week. This is unusual, and not a lot of time to make revisions. Despite the constraint, our team was able to deliver high-quality feedback sessions with really interesting results.              


What we tested in round one

Figure 1.2: A screenshot of the application form we tested in round one

In our first round of testing, we were able to leverage a staging environment for the current form. We had two separate flows for users to walk through: one for webinars (which I'll refer to as a sign-up form) and one for trade missions (which I'll refer to as an application).                                          

Figure 1.3: Notes from the first round of testing

What we found in round one of testing

  • The less information we ask for and display, the more likely we are to see completed sign ups
  • When we ask for a users title, we should ask for job title and not prefix
  • Users want to see event details immediately after completing their registration, as well as a follow-up email with those details
  • Legal terms, in current form, are too long and get in the way when displayed fully
  • Users want transparency around eligibility requirements to avoid wasting their time
  • Users really enjoyed the ability to keep themselves updated on similar events
  • We needed to validate additional questions in testing

Graphical summary, including icons and text, of research insights from first round of feedback. 1: The less information we ask for and display, the more likely we are to see completed sign ups. 2: When we ask for "title" we should ask for job title, and not prefix. 3: Users want to see event details immediately after completing their registration, as well as a follow-up email with those details. 4: Legal terms, in their current form, are too long and get in the way when displayed at full length. 5: Users enjoyed having the option to keep updated on similar events. 6: Users want transparency around requirements for eligibility to avoid wasting their time.
Figure 1.4: Insights from our first round of testing

What we changed after our first round of feedback

We heard from users that they wanted to be able to add a webinar to their calendar immediately after registering: we added that feature for round two. We heard that users didn't see much value in asking for a prefix in 2020, and instead preferred to be asked for their job title. This makes sense to me: it's much more relevant to extracting value from an event (or being contacted about future events).

Figure 1.5: A screenshot of our work with stakeholders to summarize the research

Figure 1.6: The "add to calendar" feature implementation that users liked

Figure 1.7: The short, plain language explanation before a user commits to signing up

We needed to continue to be transparent and clear about the value of the events users were signing up for. We put effort into adding descriptive mission details before a user takes time to apply to attend a trade event: that way, the user can decide if the event is right for them before submitting their application. This was formatted in simple, plain language: here is what the mission is about, this is what role you would play on the mission, and this it the type of result you can expect too see from attending.

We also transitioned our previous one-page format to multiple pages. By breaking up the content, we hoped that users would feel a better sense of progression and understand where they are in the process more clearly. We did our best to condense the legal documentation, and avoid overwhelming the user with content on any one page.

Conducting a second round of testing

Figure 1.8: The additional application flow we tested in the second round of feedback

After those changes were made in Figma, we moved into an additional round of testing. Like so many of our projects, we are encouraged to take on a teaching role with our ministry partners in the broader public service to help communicate the value of good design. We coached one of our stakeholders through hosting a session in the second round that was quite successful.

What we found in round two of testing

  • Providing as much rich, detailed information as possible as early as possible will provide the most value to users. What are users getting out of attending an event?
  • Keeping the request for a phone number optional: not all users want to be contacted by phone
  • Making it clear to users how and what their data is being used for will make them more comfortable with submitting that information
  • Content design is incredibly important to a well-designed form: removing any ambiguity from descriptions or questions goes a long way for user satisfaction and retention

Balancing business goals and user needs

The balancing act between business goals and user needs is something that comes up often in our work as a lab: in this case, our ministry partner was committed to collecting as much contact information as possible so that they could reach out to users to help. While the intention behind this is to help, it ends up leaving the user discouraged when they enter all their information just to be told they aren't eligible for an event.              


We encouraged our partners to think hard about how they can add value for their users from the first point of contact (the form), rather than prioritizing the added value of a later point of contact.                              

Changes we made based on our second round of testing

Figure 1.10: A screenshot of our notes from the second round of feedback sessions

Now that we understood more about our users and what makes an effective form, we were able to make changes to our prototype before providing it to our partners.

Users asked for the content on the 'Success!' page to be more detailed, and provide relevant information for attending the event. The same could be said about the confirmation email they received: users want clear, concise information that has all of the relevant information for attending their event, and not much else.

We took out some redundant headings and tried our best to simplify the language and jargon wherever possible to avoid confusion. We got descriptive with the fields that confused users, and showed the users where they were in the process more clearly by showing what step of the process they were on. We also prioritized eligibility questions, so that users who were ineligible for a trade mission did not go through the entire process only to find out at the end that they were not eligible.                                                  

No items found.


Final recommendations for MEDJCT

  • Must make sure the value proposition of the webinar or trade mission is immediately clear
  • Users expect to spend no more than 5 minutes in the sign-up process
  • Be descriptive about where users are in the application process and simplify the amount of information displayed on page as much as possible
  • Users are more likely to submit their data if we are open and honest about how we are using
  • Collecting only the truly necessary information will lead to higher retention rates and better attendance at events



We faced some interesting challenges with this project, but ultimately things went as well as they reasonable could have. Squeezing 12 feedback sessions, up to an hour each, into a span of one week is something I'm proud of. It's also worth mentioning that despite a challenging set of push-back from stakeholders regarding user data, when we showed them the evidence of users being put off by the excess collection of data they were very receptive.


With more time, it would've been nice to further explore specific user groups and further analyze what exactly motivates users to sign up for events. We spent much more time researching, prototyping and testing the potential solution than we did truly understanding our core users.