…she’s relentless in her approach to finding the best way to tell the most compelling customer story. She’s thoughtful and deliberate in her work, which shines through. One stakeholder shared ‘this is the best copy we’ve ever produced.’”
Tracey C.
Former client
Microsoft
ShareIT was an internal company app that helped field sales teams share details of their successes. The goal was to help peers get ideas, access resources, and improve their solutions. The app featured case studies, resources such as code samples, and peer-recommended best practices.
Shared resources were voted upon and recognition was given to contributors. Friendly competition between the divisions helped encourage app engagement.
I was brought in during the initial wireframing phase due to challenges with the original vendor. I completed content design and worked on the visual design of the app. I helped with the project through launch, however, due to the sensitive nature of the content, I was never able to view the published app.
This graphic helps clarify how my role related to the overall end-to-end process. Where some elements were out of my scope on the original process, I’ve included a point-of-view or recommendation to demonstrate my thought process.
“How can we create an engaging experience that applauds ingenuity, fosters knowledge-sharing, enriches customer offerings, and increases sales?”
Joe is rarely in the office; he travels to partner companies 50% of the time. He often works in airport lounges, on planes, and at hotels. His time on the computer is mostly spent creating pitch decks and gathering code/resources for new solutions. He’s a heavy consumer of peer-submitted information to build the best solutions for partners, and to stay on top of how technologies are being used.
ShareIT fostered peer knowledge-sharing to help maximize field innovation. Division sales priorities were cleverly embedded within the app to help drive sales goals and create frictionless access to shared resources.
Due to the highly confidential nature of the content, this app heavily restricted access. Only the [client confidential] Developer Field Sales Team and administrators were provided access.
The inclusion of the division metrics within the app experience made a tremendous impact on how the division could demonstrate its progress. And while this was beneficial, it posed a tiny challenge: Team members required substantiated data on how they each made a direct contribution to the division’s objectives during their annual review. The app was designed to provide this, but special care needed to be taken in order to prevent users from falsely inflating their performance.
From a content design perspective, I was mindful in how to structure the rating, voting, and “adopting” system so that it accurately depicted the value of each submission and prevented any misuse.
To help users glean information at a glance, I focused on moving toward replacing text with visual markers where possible. I introduced iconography to denote content category, and used color as a means to distinguish the key pivots of internal-only vs. externally approved content.
These shifts provided an immediate “read” by scanning, and the simplicity of the visual language helped users learn how these elements were used quickly and easily.
I redesigned the layout to feature a clear visual hierarchy, and to align with more natural eye-scanning patterns. Each interface was designed to be digestible at-a-glance, knowing that users are predominantly scanning before they commit to reading.
The paragraph content was separated from smaller detail information, and interaction/buttons were placed in their own region, separate from the small details.
Each asset featured an excerpt with all the metadata needed for a user to decide if he/she/they wanted to click further. The content cards were used as search results, which meant that multiple would be consumed at one time.
The layout of the content cards were redesigned to be scannable, digestible, and to allow the user to lean on the visual elements as a first means of “reading” before having to read every detail.
Due to the nature of the app being restricted to members of a specific internal company team, many of the labels would not be appropriate for a different audience. I judiciously chose terms and labels that featured their internal language, yet were still logical and intuitive for the experience.
The structure of the submission also presented an opportunity to maintain a scannable, digestible format in addition to helping the end-users understand how information needed to be presented.
One of the elements that we designed into the app was to align each submission with the sales goals and measurement system of the organization. But this posed a unique challenge: because a team members’ ability to concretely demonstrate success, this app became a key tool in the team’s arsenal to prove their contribution. As a result, users had incentive to contribute as much as possible. However, this could backfire, resulting in poor quality submissions.
To foster the peer-sharing spirit and team engagement, each submission could be rated and voted upon. Each submission could receive an “upvote” or “like” by peers. But given the sensitive nature of how this information directly fueled recognition, additional barriers needed to be in place to avoid false inflation.
We played with labels such as “vote” or “recommend”, but neither of these accurately conveyed the scope of what a user needed to do to provide recognition.
As a result, the term “adopt” was chosen. “Adopt” implied the reader would be using this information for something–which was precisely the behavior we were aiming for.
To reduce false inflation, we designed the system to require further details from the user adopting the solution. Notifications provided a space to add comments and information, and the user was informed that this information would be publicly posted for all users to see.
These additional barriers and mindful approach to the details helped provide the administrators with an active, engaged community that shared their genuine feedback from the shared resource.
The initial design featured placeholder content and labeling. The intention of the initial vendor was to create a “cool and clever” app, but in many cases, the chosen terms were actually detrimental to the overall experience.
“Submissions” were originally labeled “my items”. While I understood the intention of aiming for casual terms, the concept described was a sales win submission that included a thorough writeup, attached documents, code samples, or a variety of other assets. While the client didn’t love the sterile nature of the term “my submissions,” it was a more accurate and intuitive description.
“My dashboard” was originally labeled, “my area.” A non-native English speaker provided the UI text, and this was a prime scenario where a native speaker is helpful. In some cases, “my area” could refer to an individual’s [ahem] personal region. The team had a good laugh as I explained why that one needed to change. 😉
Wireframe view
Unfortunately, I was not able to participate in any testing of the app. But in the interest of sharing my approach, here are the tests that I would recommend confirming from users:
The ShareIT app was an excellent example of how the behavior and intention surrounding the app experience must be thoughtfully explored to create the most effective solution.
Key learnings: