Engineer Insightful Shiny Apps with Behavioral Science (Jeremy Winget, CrossStack) | posit::conf
Death by Dropdown? Engineer Insightful Shiny Apps with Behavioral Science Speaker(s): Jeremy Winget, PhD Abstract: Opening a Shiny app to endless dropdowns and scattered filters leads to immediate disengagement and feeling like "death by dropdown". This talk introduces the Behavioral Insights Design (BID) Framework, a behavioral science roadmap that transforms overwhelming dashboards into guided user journeys. Using the "Interfaces Need A Smart Vision" mnemonic, we'll explore five stages: Interpret user needs through data storytelling, Notice cognitive friction points, Anticipate user behavior, Structure the application, and Validate & empower users. Drawing from established theories and real-world production examples, attendees will see how applying behavioral science can dramatically reduce the time between "Where do I even start?" and "Aha, now I get it!". You'll leave with practical techniques using the new {bidux} package to help transform user confusion into confident exploration and build dashboards that guide users toward better decisions (and fewer ghosted users). BID Framework - https://github.com/jrwinget/bid-framework bidux docs - https://github.com/jrwinget/bidux posit::conf(2025) Subscribe to posit::conf updates: https://posit.co/about/subscription-management/
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
All right. Who here has ever opened a dashboard with 18 or more filters spread across six tabs and wondered what you were even looking at?
Let's see some hands, right? Now I want you to imagine that you're not a data scientist, right, you're an executive who has to make a decision in the next 10 minutes, right? This might be you frantically clicking around, trying to make sense of things, or maybe you have some bigger feelings, right? Truth is, we've all probably been there, right, and it never feels good.
So, welcome to my dashboard support group. Let's do a quick check-in. Raise your hand if you've ever designed a UI with more than 10 filters, drop-downs, toggles, whatever. Keep them up if you've gone over 20. Nice.
All right, how about this? Who's ever had a client ask for just one more drop-down when you knew it was gonna be too much? All right, if you're nodding along to this, no judgment here, you're among friends.
My name is Jeremy, and I've been there, too. I'm a psychologist by training, but probably not the type that comes to mind when I say that. A lot of folks, when they think about psychology, they think about couches and therapy, but the field itself is really driven by data. And my journey took me from studying how groups make decisions under pressure to accidentally designing systems that cause that pressure to then figuring out how we can fix them.
And after years of building dashboards that were technically great, but didn't quite land with users, I had this realization. A lot of dashboard failures aren't technical. They're psychological. They don't fail because of the wrong chart type or the wrong database. They fail because we're making them for humans, and humans are complicated. But we can engineer for psychology just as much as we engineer for performance.
A lot of dashboard failures aren't technical. They're psychological. But we can engineer for psychology just as much as we engineer for performance.
The dashboard disaster
Let me show you what I mean. This is a dashboard from a client of mine. Details blinded, of course, but they had built a really impressive dashboard themselves. They had lots of filters, customized views, and despite what you see here, they actually had some really cool visualizations buried in some of their deep dives. The client loved it. Users could analyze anything they wanted, except they never did. They opened the app, and shortly after, they completely deserted it and found creative workarounds like Excel.
So, we collected some telemetry data for about 30 days, and just to kind of get an idea of what people were doing with the dashboard. We rolled this out in a minor update to get some users engaged in just to see what they were actually doing with the application. And it painted this user journey clip of despair here.
95% of users, they opened the URL. Fantastic, they were really interested in it, even though they'd seen this dashboard before, and we told them it was just a minor update. 88% went further, actually opened the dashboard, so they got past that landing page. But this is where things get brutal. About half only used one filter, just one. And about a fifth returned after a week. So, this chart is screaming at us, stop doing this to your users. Something is wrong here. But how do we know what that is?
Behavioral science and the BID framework
Well, with behavioral science, which is the study of how people think, feel, and act. Typically in the context of decision making. But across decades of research, what we find is that people are rational, but in surprisingly predictable ways. And so for us as developers, this is actually good news, because we can understand that strange user behavior of ours and design for it.
So here's a classic study to illustrate what I mean here. Researchers set up a tasting test at a grocery store and varied the number of jams that they had on display at this table. And in the big display condition, there were 24 jams on the table. In the small display condition, there were only six jams. And the big display with 24 jams actually attracted more shoppers. 60% of people stopped, whereas only 40% of people stopped in the small condition. But only 3% of people in that large condition actually bought jam, whereas 30% did in the small condition. So that's a convergent difference of 10 times.
And so this is exactly what's going on with our dashboards, right? We're seeing more features and more options attract attention, but paralyze choice.
And so paradox of choice is one key component here, but there's a lot of concepts in behavioral science that we can pull from that are applicable to dashboards. We don't have time to go through all of them, I'm just gonna pull out some common themes here, just talk really high level about them, because they're not just abstract theories. These are engineering principles that we can leverage in our dashboards.
Cognitive load, for example, right? This is how having too many choices can actually overwhelm our mental capacity. So think of this like RAM. Your users have processing limits, and each filter adds a processing cost.
Progressive disclosure is the idea that we're kind of hiding complexity until it's actually needed, right? And so we're showing that vital information first, those key points up first, and then just revealing more later on. It's kind of like lazy loading for human cognition. And then for immunoflex, I'll show you a more concrete example of this, but this is how basically the same exact data can show two very different stories. So revenue being up 15% might be a true statement, but it could also be true that it's missing the target by 5%. And so unless folks are talking about that, they might be coming from two very different places.
And so when we apply this to dashboards, this might mean showing three filters instead of all 18 at first. It might mean showing summaries instead of those detailed outputs, right? And so this is how we start to engineer for the user experience.
But what if you don't know anything about behavioral science, right? Well, you fall back on things that you do know something about. And I bet you'd know a little something about road trips, especially if you took the road trip here, right? And so engineering apps with behavioral science is a lot like planning for a road trip. You need to know your destination, you need to anticipate the hazards, and you need to make sure everyone arrives there safely. Right, and that's where the behavioral insight design or the bid framework, right? The five simple stages that guide you through this process and help prevent those dashboard disasters that we've all seen.
And what makes this different from other UX advice is that it's a concrete step-by-step framework built on decades of research. And each stage builds into the next, so this provides this continuous feedback loop that helps you keep improving your dashboard whenever you'd like to revisit that. Plus, the whole thing is bundled into an R package, so it does levy lifting for you.
So meet BidUX, right? It's designed specifically for our workflows as Shiny developers, and it works with any dashboard that you've already built. So you don't need to refactor, no need to start over. If you have telemetry data, that's great. It'll actually analyze that data and give you data-driven insights. But if you don't have any telemetry data, you can still just use simple verbal descriptions based on what you've seen or what your users have reported. But whatever inputs you provide, it will use those to auto-suggest improvements based on the available research.
Think of it as having a behavioral science in your console. Always available, never judges, and doesn't charge by the hour.
The five stages in practice
So let me show you what this process actually looks like. So first we start with the interpret stage, the why behind the dashboard, because the central question here is really what's driving the focus for your users. It's what they're coming to the dashboard for in the first place.
And that data story helps create the narrative structure for this. So humans are hardwired for stories, not pivot tables. Context, the hook, tension, resolution, all of this is the structure that folks are looking for with their key insights. And so we build that in from the start.
And then finally, users and personas help us developers take that user perspective. Project manager probably doesn't think in SQL terms. They think in business outcomes. So we need to make sure the dashboard bridges that gap.
And then putting all of that together, the function will summarize that and let you know if you're missing any information. And if you are, it's probably a good time to go back and check in with your client, make sure you're considering their perspective, because when we neglect that context, we end up building friction points into our user interfaces.
Which is what the second stage, notice, is about. So going back to my client's dashboard, this is a summary of the telemetry data we collected on the filter usage. So 14 filters here, hardly ever used. And half of those were hardly even touched. So this is technical debt visualized. Each unused filter, that's maintenance overhead. There might even be database queries running on the back end for those unused filters. And so this is why the notice stage focuses on finding those friction points.
The package auto-suggests relevant behavioral theories with confidence scores. So in this case, it's suggesting cognitive load theory with a 90% confidence score. But it might also suggest choice overload or decision fatigue. It depends on the context from those users or personas and what you're feeding into it at this stage. It starts to transform that user feedback of it's confusing into something more specific, like an engineering principle of cognitive load exceeding working memory. So you're not guessing anymore, you're addressing identified psychological barriers with code changes.
The package will also suggest bias mitigations based on the dashboard context and personas. So again, using that previous stage information, it will suggest specific information processing biases. And also specific ways to mitigate them. So in this case, we're getting an anchoring, framing, confirmation bias. And these are all bugs that it's identifying in human cognition. And these are bugs that affect every user in some capacity. But now we can start to guard for them.
So in my client's case, we had multiple stakeholders who were coming from different teams with different perspectives. And so we focused a lot on framing effects. And so in this case, we had added a toggle. In the progress or the gain frame, this was showing that relative difference between the raw value and the client's benchmark. And so this was highlighting the achievements that the marketing team was interested in. But when we switched to a loss frame, or a gap frame, we're looking at the raw values versus that benchmark instead of the relative difference. And so now, this is looking more at the improvements that still need to be made. And so with this, we have the same data, but a very different story. This is proactive bugging for human psychology. Because now teams can coordinate and align on what they're actually seeing and what their concerns are.
Okay, so at this point, we know what the dashboard's for. We've looked at the problems we need to fix. We've looked at the targeted biases to guard against. And now, it's time to put everything into a structured information flow. All right, and so using BidStructure, we can get specific implementation suggestions. Not just reduce complexity, but use BSLibAccordion for progressive disclosure, for example. The package shows which components should map to the theory. So it's tying specific functions from Shiny, from BSLib, from different packages that we might use to build into our workflows to these principles. And it gives multiple options and suggestions to try.
So for example, see this F pattern here? This is how most users are scanning dashboards in Western cultures. Top left gets most of the attention. Bottom right might as well not exist. And so this structure stage is putting the most important information up front where the eyes will naturally go. So critical KPIs, summaries, those are placed at the top. The supporting details follow the F pattern, and deep dives progressively get disclosed towards the bottom.
And finally, from here, we get to the last stage. We'll feed this into our validation stage, where we validate not only what we've done, but we also look for ways to empower user engagement. So this helps you as the developer know whether the dashboard is working as intended, but also helps users know what to expect next. It'll guide developers through all the changes, through iterations, and it will also suggest, again, different ways of not only empowerment, but even collaborating between your users, your end users and teams.
So for example, in this case, we looked at executive summaries, because this client had, again, a lot of different teams coming from different backgrounds, and they really wanted these key takeaways to be up and prominent. And so what we did is we looked at the executive summaries, we placed those at the top, and then we tailored them to the user personas. So for executives, they were a little bit more high-level, targeted, action-oriented. But for developers or analysts, those were a little bit more tech-oriented and a little bit more low-level. And so this generates also other checklists after this to validate and also look for other accessibility checks to really help you as the developer guide and create those aha moments for your users.
The transformation
Validation isn't the last stage either. It can feed back into interpret, so creating that feedback loop. But let's take a moment and look at the transformation of my client's dashboard here. So here's the dashboard disaster again. Technically perfect, but psychologically broken. Had everything except for its own users.
All right, here's the same dashboard, but with a transformed user experience. We have clean executive summary at the top. Users know immediately what matters and what to do about it. We have progressive disclosure, complexity available, but isn't required. And if you want to get even more into the details, we have those further at the bottom end of the deep dives. We also have smart defaults that are based on actual usage patterns, not just assumptions. And we telemetry the data, so the before and after.
We see filter usage up 38%. People are actually exploring instead of abandoning shit. Return rate up 75%. They're actually coming back now. And this is the ROI of behavioral science. It's not magic, it's not AI. It's designing for how human minds actually think. We're reducing that cognitive load, we're aligning with mental models, and we're creating a clear information hierarchy.
And this is the ROI of behavioral science. It's not magic, it's not AI. It's designing for how human minds actually think.
That gives us more users, deeper engagement, and stronger retention, because we're removing obstacles instead of just adding features. And as a developer, that means less support tickets, less feature requests, because your users are starting to find what they need and figure it out on their own. It also might mean potentially better performance reviews, because now you're building products that are driving value. And that's really the difference between just building in features and building products that people love.
And here are just some more results from other clients from the last year or so of when I've been integrating this BID framework here. And on average, we're just seeing people engage with the dashboard longer. It's performing better in general, and we're getting rid of unneeded, because we're getting rid of unneeded processes. And we're seeing more user traffic across the board. And this is just becoming effective across the board, across these different domains, because human psychology is predictable, even as irrational as it might be at times. Your finance users have the same working memory slots as your healthcare users, and so this framework adapts to different domains, because the principles remain consistent across those domains.
Getting started with BID UX
And here's the really nice part. Implementing this psychology is just a few lines of code. If you have telemetry, simply load it with the BID telemetry function. And then here, I'm just filtering down to one of the critical issues identified, and then adding the central question to contextualize everything that follows.
Then I use BID notice. It's a BID notice issue. It's a bridge function for the telemetry data that will feed and populate the following stages. From there, it's just running through the rest of the steps, and optionally ending with BID report. This will create a markdown report for PR, for documentation, whatever your needs might be.
Now, if you don't have telemetry data, that's not a problem either, because you can simply fill it in manually based on your observations or user feedback. So, start by creating your data story to structure the dashboard's narrative. Identify the friction points, because even without data, you probably know where your users are struggling to some extent. And we have that same five-stage pipeline with the same actual insights.
And this BID report function can generate markdown, can generate text, or HTML, depending on your needs. But this overall framework is really guiding you whether you have a lot of telemetry data or just simple user feedback. And you can start this during the early age of development. You don't need to wait until you've deployed the dashboard. You can iterate on this before problems even surface for your users.
BID UX is currently available on CRAN, so installation is really simple. Just simply install and load the library, and then run through those five stages, because even with minimal input, you get valuable suggestions. And there's also a BID concepts function, so if you're unfamiliar with a function, you can explore that. It's kind of like having a psychological textbook right there on hand.
So, with that, I've also compiled a lot of resources here for you to check out. These slides will be in the BID framework repo. The BID UX repo is also listed there, and I love how this community learns and shares from one another, so please feel free to connect with me. I'd love to hear and learn from your dashboard challenges as well.
And if you remember just one thing from our time today, dashboards don't need features, they need fewer obstacles. Every dropdown should just bring our users closer to Insight, not further from it. So, let's work on that together, and before I close, I want to give my heartfelt thanks to the Posit Conf organizers for creating this great space, the community for pushing things forward, and for all of you for caring about your users. So, thank you.
And if you remember just one thing from our time today, dashboards don't need features, they need fewer obstacles. Every dropdown should just bring our users closer to Insight, not further from it.
Q&A
So, the first question is does BID UX, does the BID UX package rely on external services and or LLMs because they work at a university with sensitive data, so they're interested in how you work with that data? Yep, no, there's no LLMs. It's basically fuzzy matching, smart matching, based on a dictionary, so kind of mapping keywords to concepts right now. So, no LLMs, no external services.
Are there any possible ways to expand BID UX to Quarto dashboards? Yes, it's been on the roadmap. I'm currently thinking about that, but if you have any insights or suggestions, I would love to hear them because it's definitely something I'm thinking about.
All right, last question. How does the package interpret or scan the dashboard beyond telemetry? Are there some of these features unavailable, are some of these features available without telemetry set up? Yes, it's fully functional without telemetry. It's just telemetry will give you more specific and deeper insights. So, the more information, the better.
All right, actually, one more. How did you collect analytics for dashboard usage, especially filter usage? Shiny telemetry package. All right. That's it. Thanks, Jeremy. Thank you. Appreciate it.