Congrats on launching with Localist!
As you roll out and promote your platform, you will inevitably receive feedback from your community. We’ve gathered our top pointers on how to navigate this next phase of transitioning to Localist, but please note that these tips are evergreen and can be consulted at any time post-launch.
Rules of Thumb
Before your team starts to accept or work through community feedback, we encourage you to follow our “rules of thumb” that have helped other customers stay grounded during your post-launch phase.
Commit to a “cooling off” period post-launch
Take a step back and give your team a much needed post-implementation breather! Switching to Localist is also a big change, especially for admins, so waiting to dive into making changes helps eliminates moving on reactionary feedback that is rooted in change, not usability or confusion.
- We recommend at minimum 7 days or up to a 30 day cool off period before turning feedback into action items.
Communicate Your “Why”
Proactively make it clear that there is a team not just behind the platform, but behind the platform’s implementation that thoughtfully made the best decisions for their community and goals with a clear way to contact the team. We encourage you to proactively provide the following to new admins and key stakeholders:
- What is Localist?
- Why did you switch to Localist?
- What goals and initiatives will Localist help support?
When gathering feedback, encourage your admins, stakeholders and community to describe solutions, not just the problem they’re experiencing. For example, if a Filter name isn’t clear, ask what they were expecting.
- Take a page out of our book and consider a similar form to our Suggestion Box.
Focus on the Big Picture
Ultimately, be mindful that once you make a change, it can be even more frustrating to make another change or revert back to the original. Before moving forward with acting on feedback, ask yourself:
- Is this feedback being driven by an edge case?
- How many admins and/or events would be impacted?
Now that you have feedback from your community in hand, ask yourself the following questions to further prioritize or archive the feedback.
Who is providing the feedback?
- Target Audience → how does this impact feedback? For example, a business owner with a Place Page vs. a tourist browsing a platform.
- Niche or not? → how broadly applicable is the feedback?
Is it an opinion or base expectation?
- Opinion → Ex: “I don’t like the red button”
- Base Expectation → Ex: The blue text on the red button is hard to read”
Is this a nice-to-have, need or blocker?
To further dig in, consider the urgency behind the feedback being shared.
- Nice-to-have → wanting to change the time and date formatting
- Need → a Custom Field specific to including health & safety guidelines
- Blocker → a Department is missing on the platform so a corresponding Widget can’t be made
Does it require a platform change or added to admin training?
- Platform change→ there aren’t enough events showcased on the homepage
- Review in training→ outlining what is eligible to be Featured or Sponsored
When to Take Action
These are the areas that do not need to wait for a cool-off period to end and/or may not need further discussion:
- Messaging (or lack of) → Ex: adding an expected approval turn around time to your submission form if that becomes a common question
- Groups, Departments, Places → these can be added at any time
- Accessibility → Ex: ensuring a high color contrast ratio for text/back ground colors
- Responsive design → Ex: ensuring that your branded mobile experience is on par with the desktop experience
These are the areas that we would recommend allowing a cool off period before diving into making changes:
- Classification → you may receive feedback on the naming (“Arts” vs “Arts & Culture”) or what was included vs. not included. Since these changes impact public submissions, admin management and public browsing, we recommend not making these changes lightly.
- Branding → simply switching to Localist is enough of a visual change that allowing some time between launch and making changes will help you determine what was reactionary feedback vs. what changes would improve the visual identity of the platform.
- General Policies → whether it’s workflow/permission related, or how you’re determining what events are included on the homepage, we recommend allowing time for folks to settle in.
- Features available → during onboarding you may decide to remove the comments section or to not populate a photo library. We recommend outlining any reasoning behind these decisions in admin training and avoiding turning features on then off again.