I recently sat in on a beta-user training session with a Pica9 customer in the banking industry, to see how their power users responded to the launch of their new local marketing system. I found the experience eye-opening, and thought you might too.
The session started with a 5-minute introduction from the marketing lead. The rest of the time (85 minutes!) was devoted to watching the 20 attendees use the system to complete a slate of typical tasks—find and download a brand-supplied asset, customize a business card, create a marketing flyer, order branded merchandise, etc. As the attendees worked through their tasks, they called out questions and impressions and the implementation team responded in real time.
It was transparent. It was productive. Occasionally, it got a little noisy. And, I have to say, it was a good bit of fun.
By the end of the session, three lessons emerged that lead me to believe everybody who has a local marketing or DAM system should run sessions like this—not just during rollout but as a regular user-experience audit.
Roles and Permissions Should Always Be A Work In Progress
One of the great benefits of a local marketing platform is that you can deliver to end users just the materials and assets they need, while insulating them from content that isn’t appropriate. During the beta session, the marketing team found that their first crack at user-permissions had inadvertently locked some users out of access to things that they need.
With a few behind-the-scenes adjustments, the team addressed those issues—and lightbulbs began going off among the users. They began to see how their “view” of the content was being tailored to their individual needs and how quickly and easily adjustments could be made. The marketing team, meanwhile learned about use cases that they hadn’t taken into consideration in their original planning. It was a win-win moment that inspired everybody to dive deeper and contribute more thoughts and responses. What a great, collaborative way to begin!
People Will Adopt Your System, If Your Organization Is Clear
When our customers launch their systems, one of their top objectives is usually to put everything that local marketers need in one place, rather than having resources spread across a number of different systems.
But while everybody wants an “all-in-one” system, larger asset libraries can be daunting to search. New terminology can be unfamiliar or confusing. And even though the system may be functioning perfectly, from a technical perspective, frustration can build among users who can’t easily find what they need.
The marketing team had wrestled with these issues during the implementation—and they were eager to see if they’d solved the problem properly. Several times during the beta session, we heard attendees express a moment or two of uncertainty about where materials might be found on the new system. But each time, we saw them experience that “aha!” moment when they discovered for themselves the logic behind the folders and categories that the marketing team had created.
This process of discovery seemed to be inherently satisfying. As one attendee put it, “This is impressive. I can tell that you guys didn’t just throw this together in a month or two. You really thought it through.”
What lessons emerged? Take the time upfront to think through the organization of your assets from an end-user’s point of view. Don’t rush the process. Your aim doesn’t have to be instant access to every asset. Your users will respond enthusiastically when they discover a clear organizing principle, based on brand-specific language that they know and use every day. If you can achieve that your chances of winning the adoption battle go up dramatically.
Be Transparent About What’s On Your RoadMap—And What’s Not.
Several times during the session, attendees expressed a desire for a certain feature or capability. Often, these requests were expressed in the language of “bug fix.” This can be a difficult moment for the manager of a newly launched system. The implementation team handled these moments with great clarity, explaining upfront when a feature was not supported, and if there were plans to incorporate it in the near future (within 3 months).
I was impressed both by the transparency that the marketing team brought to the discussion, and the receptiveness of the attendees. Of course, you want to be able to say “yes”, or at the very least “soon” whenever a user points out a shortcoming in your system. But there are compelling reasons to be clear and conservative about what the system supports and what it does not.
- First, you’ll preserve the trust between the application team and the power user community. This will be essential in the days ahead.
- Second, you’ll prompt power users to find innovative ways to use the system to accomplish their needs. Over time, these will help you better understand the use case and determine the right solution.
- Finally, experience with the system will help you build a business case for an enhancement, by helping you to quantify the business impact caused by the lack of a given feature.
What have we learned?
As the session drew to a close, several of the attendees took time to compliment the marketing team on their work. These weren’t just your typical “feel-good” comments. There was a clear sense in the room that the system could have a meaningful positive impact on the business, and appreciation for the careful work that the marketing team had devoted to that end. In my view, that sense of gratitude for the capabilities, and appreciation for the complexity behind it, is exactly what you want to foster in your user community.
What I learned yesterday is that people who use our tools have very practical needs. They want to buy something without using their own credit card. They want to buy something without using the corporate budget. They miss the apply button when it’s at the bottom of the screen.
But if you overcome these hurdles, you find yourself reaching the new normal. And that Google meeting was quite effective. You could deal with one issue while everybody else was having a go at the platform. You could make some minor adjustments to permissions to help fine tune an experience.
Sure, it took a combined 12 hours of time. But what we learned is that when you embrace your power users, when you bring them inside the application design “tent”, you end up getting closer to the best reasonable user experience.
Don’t shut down the legacy system too fast.
Take your time with the organization. Your power users may not intuitively understand how you’ve set things up at first. But if they begin to sense the logic behind your organization, if they can sense the care you took in how you defined and used your terms, they’ll adopt your way of thinking—and help you enrich it.
If you make a roadmap promise, deliver on it.
In every system, there will be small inconveniences. Users will find these quickly and will usually be vocal about them. There’s a temptation to say you’ll correct the problem and to add it to your growing list of roadmap items. Try to resist that urge. Tell your power users up front that the system doesn’t have the feature they are looking for and likely won’t in the foreseeable future. Watch to see how they process their disappointment. It might be that they change their ways without discomfort and the request fades into history, forgotten. Or, they may find a different way of solving the problem that neither they nor you could see. And if the pain persists, unabated, you’ll be in a much better position to make a business case for starting a project to address the problem head-on.
Embrace Your Power Users.
