[Product & Design] - Revamp insights experience

[paolodamico]

This issue is intended as the basis for discussion (from a product, design, UI/UX perspective) a full revamp of the querying (insights) experience. Engineering and implementation discussions are out of the scope of this issue.

Goal

We know from customer feedback and our own dogfooding that there's a lot of room for improvements here, however the concrete goals are:

1. Make it as seamless and painless as possible to get answers and insights from PostHog for anyone. This in particular encompasses two cases worth standing out: insights for users with little experience on product analytics, and insights for new users to PostHog (activation).
2. Enable discovery and use of advanced querying features without interfering with 1. In particular we want these features to be intuitive and discoverable by users who're looking for them, but unobtrusive for users that don't.

Success metrics

• This change should improve our activation (discovered learnings) (see https://github.com/PostHog/retention/issues/17 for more details).
• This change should improve our core experience usage (ongoing discovered learnings, more details to come), and indirectly our retention (though retention in particular will not be measured directly).
• We'll inevitably have to incorporate some qualitative feedback from users on this as well, as some of the impact of these changes may be hard to measure from a pure data standpoint.

Additional context

• From customer support, we've qualitatively seen that answering certain questions is unintuitive (not clearly communicated in our product), or requires some creative workarounds (which shouldn't be the case).
• As part of achieving the goals here, we may consider removing some unused features.
• While this may be more tangential with implementation, it's important to note we'll have to be very rigorous in making sure the overall experience is well polished (counter examples today: multiple clicks required to apply filters, filters dropdowns randomly scrolling the screen, textboxes/dropdowns too wide or too narrow, ...)
• If we're successful with this, this might actually supersede Super guided query running #2984.
• This would directly/indirectly address a bunch of related issues: Dropdowns too narrow #4045, Add commas to big numbers on dashboards #4044, Make saved reports a top-level feature #3408, Show warning when saved report already exists #3407, Multi select property values #3391, Slightly confusing UX for session filters #3384, Improve UX for formulas in trends #3375, Trend graph filters not preserved as expected #3355, UI bugs on insights (tooltips & annotations) #3356, Unintuitive filter "autocomplete" #3133, Update dashboard button doesn't update reference #2980, [EPIC] Insight improvements #2877, EPIC: Filters UX 2.0 #2760

[paolodamico]

Update on our progress thus far on some initial ideas.

Option A (@corywatilo): https://posthog.slack.com/archives/C01G8S5T08Z/p1618942457009400?thread_ts=1618942455.009300&cid=C01G8S5T08Z

Option B (@paolodamico)

Option C (@paolodamico)

[macobo]

Aside - whatever design we end up here should also accommodate expanding what our filters can do: https://github.com/PostHog/posthog/labels/analytics-filters

A really important one is #2594 and #2273, but perhaps also things like #2247

[samwinslow]

Option A, because of its narrow size, might not accommodate the increasing complexity of filter options we will support — even now with the new "Trailing WAU / MAU" feature, it's getting tight.

Some notes about options B & C:

• Think we should have delete buttons on the right side for consistency
• It's not obvious how the user would delete a local filter
• We could replace copy filtered by with where — it reads better & is a clearer mental model for the underlying SQL

[paolodamico]

1. Agreed on the delete button
2. We need to add a delete button to at the right side (not sure if an X or trash can would work better, we might need to see in the actual version as we won't have mockups)
3. Hmmm not entirely sure if where doesn't sound too technical but I like that it's clearer, so let's go for it!

[timgl]

I'd love to try B. I think having the queries written out would make it a lot easier for users less comfortable with product analytics to understand what they're doing. It's also the most different from what we're currently doing so will be a more meaningful test.

[corywatilo]

My only concern with B is it seems like the filter option just below the event is the filtering option for the entire query (at first glance). Moving the options off to the side just requires familiarity with our app to know where to find them. If we hide the event-level filter by default (like making it an icon like in A) may be a good way to still provide the functionality (for those who are looking for it) without distracting a newer user from a more typical use case.

I do like spelling out the query like a mad lib. That's solid.

[paolodamico]

That's a great insight @corywatilo! I think we would definitely hide those if you only have one series. Unsure about what to do when you have multiple, I think we can just test it out with the built functionality and see.

[paolodamico]

Thanks for the input @macobo (missed it before)! We'll definitely take all of that into account, though we'll probably do that when reworking filters. For group analytics, I did want to take a quick stab to make sure we have some path forward (see #2247 (comment)).

Progress update

Sharing some progress update on this for everyone else's context,

1. We started working on the implementation of this on Monday. We went with Option B on the grounds that A is already too cramped, and we have several events/properties/aggregations with long names.
2. After we finish with the base option, we'll test building Option A's layout to better serve users with large monitors (though as a separate improvement).
3. We'll aim to have this ready by next week, do some usability testing then, and do an early experimental release by the end of next week.

[paolodamico]

Some solid progress on this. Documenting what we're still missing:

• Filtering experience. Local filters should be collapsed by default (opened through filter icon at the right of each row). Add more filters by clicking a plus button (see wireframes). @samwinslow
• Filtering experience. When only one series is added, emphasize only local filters. @paolodamico
• Formula. Hide by default. @paolodamico
• Split out non-visualization options (i.e. "cumulative" and bar "value") from visualization selector. @paolodamico
• UI of filter rows, zebra-striped to clearly distinguish each row (as shown on mockup). @samwinslow
• Adjust UI of "Add graph series" button. @paolodamico
• Missing icons on display config (chart visualization type, and interval) @samwinslow
• Remove event popover for PostHog-based events (as we did for properties). @samwinslow
• Handle case when opening saved insights from dashboards (the "Unsaved query" title) @paolodamico
• Change filter icon to "X" to avoid confusion with removing entire series. Either.
• Funnels. We'll probably want to keep vertical layout for them (due to the nature of the steps process, plus there's no benefit of how these are read horizontally (pending @corywatilo's input). @samwinslow
• Sessions, retention & user paths. All need to be adjusted to the new layout. @paolodamico
• Lifecycle. Remove global filters. @paolodamico
• (nice to have). Tabbed keyboard navigation. @samwinslow

Related

• Graphs new UI: Update design of tooltips #4156. @samwinslow
• Allow saving insights without adding them to a dashboard (saved reports). @paolodamico

[corywatilo]

Here's an idea for creating UIs that are more specific to each analysis type. It would require crafting how each analysis UI displays, but there are some benefits.

For example...

Retention

Building a cohort table requires specific inputs: event, returning event, view options. Optionally, you can add filters. The layout below has a few benefits:

1. Gives full width to the resulting table
2. Reduces the required inputs to a single row
3. Leaves a wide area for (long) filters, but only takes up as much space as needed

Other analysis views

I roughly sketched out how we could do similar UIs for each analysis type below. Some (like Funnels, Sessions) maybe just stay the way they are today, since there's a benefit in having some of these side-by-side.

(Happy to wire any of these up in detail if this is useful.)

[samwinslow]

Looks good! My only concern is that for retention, like funnels, the flow of time is from one event to another and I think it could still be represented by the vertical stack where the top event is the first and the lower event(s) are afterward.

[samwinslow]

Do we need to keep this open or can we report results in #2760 ?

[paolodamico]

I think you mean #4475, but definitely, we can close this now and continue there.