Sharing reports and roadmaps
Role: Sr UX Designer • Company: Aha! • Teams: UX/PM/Engineering/Security
The problem
Sharing reports and roadmaps with non-Aha! account users is currently a very heavy weight action. Our users have requested something easier that would allow them to share directly from the report itself, with anyone in their company.
“I want to be able to quickly share my reports and roadmaps with anyone, so that other teams and departments can be updated on the progress of my product roadmap.”
Goals
Design an elegant experience for sharing views with internal or external users
Enhancing the ‘sharing’ UX will allow for more non-Aha! users to become aware of our business which in turn should drive more sign ups and the viral adoption of Aha!.
Constraints
Security complications: This feature would allow sensitive and confidential data to be viewed outside of Aha! so we needed to involve our Security team early
The shared view needs to be pseudo-live (i.e. refreshed every 5 mins) so that if the report is embedded on a website with a lot of traffic, it doesn't take Aha! down
Research & Analyze
Talking directly with our customers is my favorite way to get a better understanding of their pain-points and needs. Additionally, hearing from users in their own words helps avoid guesswork and eliminate assumptions. For this project we interviewed around 8 Aha! users that used reports frequently. We also analyzed feedback around sharing reports from our Ideas Portal - we have over 703 ideas just around reporting alone!
User pain points
From speaking with our customers we where able to outline the following pain points we wanted to solve:
Incorrect access to reports leads to incorrect data shown in a report
Need the ability to share reports with people in their entire company - even if they don’t have Aha! accounts
Users find it tedious to create a presentation each time they need to share a reports internally or externally
Need more specific controls around report permissions and security, including a way to disabled a shared report
“Not having this feature makes it difficult for multiple users working in the same functional area to share reports.”
“If we share a report URL and that individual only has access to 3 of the 5 products that are in the report they are not able to view the complete report.”
Ideate & Design
For this project I started with a competitive analysis to see how other application solved this problem. This allowed me to understand what works and what doesn’t from a user's perspective. It is also beneficial to find any common usability patterns that might already exist around the ‘sharing’ functionality that our user’s are familiar with.
Lo-fi WIREFRAMES
From our learnings I was able to sketch out different design paths to help us quickly narrow down some options that would work within our limitations. The main problem we wanted to solve was with these sketches were:
Where is this new 'share' setting going to live?
What were we going to call this feature?
What would a shared report/roadmap look like for non-Aha! users?
Hi-fi mocks and prototype
Once we felt comfortable with the direction of our proposed solutions, I could start working on the more detailed designs. Building a clickable prototype at this point in the process helps me create a more natural experience of the flow and highlights anything we may have forgotten.
Validate & Iterate
Now that we had a working prototype of our suggested design we were able to get some internal feedback before releasing this to our customers to make sure the design was intuitive and solved the pain points we had found from our initial research.
User Testing
We tested the prototype on 6 people and found:
They could easily find where this setting was (yay!)
They understood the controls (yay!)
They had trouble understanding the terminology that we used (nay!)
Design Iterations
As clear as I thought my initial designs were, it turns out that people were still struggling with the terminology around ‘sharing’. I decided to divide the sharing options into two sections, internal and external, and called this setting 'share as webpage'. This is what we call it when you share a presentation - so we could leverage an existing metaphor to help the user quickly understand this new feature. Results: When we re-tested this solution everyone was able to understand the terminology! (BIG YAY!)
Development
Once we felt comfortable with the UX details we were ready to work with engineering to build the feature. Before our kick-off meeting with engineering I worked with my Product Manager to breakdown the requirements and add any edge case designs (error states, empty states, hovers, animation).
Engineering handoff
We always start every project with a kickoff meeting with Engineering, myself, and the Product Manager to make sure everyone is on the same page and there are no blockers. Since we are a remote team we will usually set up a slack channel between all teams to make sure everyone is readily available if there are any questions.
QA review
Once engineering pushed their first draft to stage I was able to start the QA process. I like to mock up any design updates needed verses typing it out as this can be much easier to understand. I added requirements to the feature outlining where the execution didn’t align with the initial design.
Retrospective
Overall I love how this project went, getting information about our technical limitations up front allowed us to narrow down some of our solutions without getting too far with the designs.
What went well
Great communication across teams allowed us to be able to make updates quickly when new requirements came in later in the project (e.g. allowing users to embed the report, not just share the report with a URL).
Lessons learned
We didn't realized how much security review would be needed for this feature so that pushed the deadline back. For future projects that required security we learned should looped them in sooner during the initial phase of the project.