creditunionwebsolutions.com

Designing Adaptive User Interfaces: A Practical UX Framework for Context-Aware Digital Products That Respond to User Needs, Environments, and Behaviors

by | Jul 12, 2026 | UX Design

adaptive user interfaces

I have been designing digital products long enough to remember when "responsive design" felt like a radical innovation. If your website rearranged itself to fit a mobile screen, you were ahead of the curve. But somewhere around 2018, I started noticing something: responsive layouts were table stakes. They handled screen size, but they ignored everything else about the person using the product. A busy parent checking their banking app at 11 PM with one eye on a sleeping toddler has completely different needs than the same person logging in from their desktop at 2 PM on a Tuesday. Same app, same user, radically different context. And most products treat them identically.

That is the gap adaptive interfaces are designed to close. An adaptive interface — sometimes called a context-aware or adaptive UI — does not merely resize and reflow. It changes what it shows, how it shows it, and how users interact with it based on a deeper understanding of the user's current situation, goals, device capabilities, and behavioral patterns. This is not about creepy surveillance or algorithmic overreach. Done right, adaptive interfaces feel less like a computer making assumptions and more like a thoughtful colleague who knows when to hand you a summary versus a full report.

In this article, I will walk through a practical framework for designing adaptive interfaces that actually work. We will cover the psychology of context, the technical patterns that enable adaptation, common pitfalls that turn adaptive UIs into frustrating ones, and a step-by-step process you can apply to your next project. By the end, I hope you will see adaptive design not as a futuristic gimmick but as a fundamental shift in how we think about user experience.

What Makes a UI Adaptive?

Let us start with a definition. An adaptive user interface is one that modifies its appearance, behavior, content, or interaction patterns in response to information about the user, their environment, their device, or their current task. The adaptation can happen at initial load, during a session, or across multiple sessions over time.

To make this concrete, consider three examples from products you probably use every day.

Google Maps adapts to environment and goal seamlessly. When I search for a coffee shop while walking, it shows me results within a few blocks, prioritizes walking directions, and surfaces walking times. When I search for the same coffee shop while driving, it shows me different results — ones with easy parking or drive-through service — and defaults to driving directions. The interface changes both what it shows and how it presents it, based on how I am traveling and how close I am.

Spotify adapts across sessions using behavioral patterns. Its home screen looks completely different for a new user versus a power user. New users see onboarding cues and curated playlists. Power users see recently played albums, personalized Discovery Weekly playlists, and listening statistics. The interface does not ask you to configure anything. It learns from your behavior and gradually shifts toward a more sophisticated, personalized layout.

Slack adapts its onboarding flow based on team size and role. When you join a small startup, the interface highlights channels, direct messages, and integrations. When you join a large enterprise, it emphasizes workspace navigation, search, and notification preferences. Slack also adapts the channel sidebar by pinning frequently accessed channels higher and letting infrequently used ones drift downward, though users can override this.

These examples share a common thread. None of them require the user to fill out a lengthy preferences form. None of them make dramatic, disorienting changes. And all of them feel natural, as though the product simply understands the user without being told. That is the hallmark of good adaptive design: it is invisible when it works and obvious only when it breaks.

The Psychology of Context: Why One-Size-Fits-All Design Fails

To understand why adaptive interfaces matter, we first need to understand context from a psychological perspective. Context is not just a technical constraint like screen width. It is a cognitive framework that shapes how people perceive, interpret, and interact with information.

John Sweller's Cognitive Load Theory shows that human working memory is severely limited. We can hold roughly seven pieces of information at any given time, and that number shrinks when we are tired, distracted, or multitasking. When a product presents the same interface to a user who is relaxed at their desk and a user who is rushing through a train station, it is guaranteed to overload one of them. The relaxed user might feel the interface is sparse and slow. The rushing user might feel it is overwhelming and confusing.

There is also the concept of situational impairment, which researchers at Microsoft and Carnegie Mellon have studied extensively. A situational impairment is a temporary limitation caused by the user's environment. Walking in bright sunlight impairs your ability to read a screen. Holding a grocery bag impairs your ability to tap precisely. Being in a noisy environment impairs your ability to hear audio cues. These are not permanent disabilities, but they create real usability barriers that a non-adaptive interface ignores.

Jakob Nielsen's work on information foraging theory also applies here. Users do not consume information passively. They actively forage for the information they need, using cues like headings, links, and visual prominence to decide where to invest their attention. An adaptive interface can surface the most relevant information based on the user's current task, reducing the foraging effort required. When you open a project management tool during a sprint planning meeting, seeing the sprint backlog first is adaptive. Seeing your entire project portfolio is not.

Two UX designers collaborating at a standing desk reviewing adaptive UI layouts across multiple device form factors

Adaptive interface design requires thinking about how the same content performs across different contexts, devices, and user goals — not just different screen sizes.

Mihaly Csikszentmihalyi's concept of flow state makes a strong case for adaptive interfaces. Flow happens when the challenge of a task matches the skill level of the person doing it. Too much challenge causes anxiety. Too little causes boredom. An adaptive interface can help maintain flow by adjusting complexity. For a first-time user, this means showing fewer options and more guidance. For an expert user, it means exposing advanced features and shortcuts. The interface that adapts to skill level keeps users in flow longer, which correlates directly with engagement, satisfaction, and task completion.

The Four Dimensions of Adaptation

After studying dozens of adaptive interfaces across web, mobile, and desktop applications, I have identified four primary dimensions that products can adapt along. Understanding these dimensions helps designers decide which type of adaptation is appropriate for their product.

1. User Goal Adaptation

Adapting to what the user is trying to accomplish right now. This is the most impactful dimension because it directly reduces friction for the primary task. Examples include: showing a search bar prominently when the user is looking for something specific, showing creation tools when the user just landed on a blank canvas, or surfacing recently accessed files when the user is likely returning to unfinished work.

2. Environmental Adaptation

Adapting to the physical and social context of use. This includes screen size and orientation, but also ambient light, noise level, network quality, input modality (touch, mouse, keyboard, voice), and even the user's posture or activity. A mapping app that switches from driving to walking directions when it detects the user is walking is adapting to environment and behavior simultaneously.

3. Device Capability Adaptation

Adapting to what the device can do, not just its pixel dimensions. This includes processing power, battery level, storage availability, sensor access (camera, gyroscope, GPS), and connectivity. A video streaming service that adjusts playback quality based on bandwidth is a familiar example, but the same principle applies to more subtle adaptations like disabling power-intensive animations on a device with low battery.

4. Behavioral Adaptation

Adapting based on patterns observed across multiple sessions. This is where personalization meets adaptation. The interface learns from repeated interactions and gradually tailors itself. Behavioral adaptation can manifest in features, content ordering, default selections, and even the timing of notifications or prompts.

These four dimensions do not operate in isolation. The best adaptive interfaces combine them. A fitness app might use environmental adaptation (detecting that the user is outdoors and moving) combined with behavioral adaptation (knowing that this user prefers running playlists) to surface a start-workout button with the user's favorite music queued. The adaptation feels intelligent because it pulls together multiple contextual signals.

Adaptive vs. Responsive vs. Personalized: Clearing the Confusion

I hear these three terms used interchangeably all the time, and it causes real confusion in design discussions. Let me draw clear lines.

Responsive design is purely about layout. A responsive interface uses CSS media queries, fluid grids, and flexible images to rearrange content based on viewport size. It does not change the content itself, only its presentation. A responsive product shows the same navigation menu on mobile as on desktop, just stacked vertically instead of horizontally. Responsive design is table stakes, not adaptation.

Personalization is about the user's identity, preferences, and history across sessions. When Netflix recommends movies based on what you watched last week, that is personalization. When a news app lets you select topics to follow, that is personalization. Personalization is often manual or based on explicit user data. It tends to be static within a session. Your Netflix home page does not change mid-movie based on your current mood.

Adaptive design sits between responsive and personalized. It is more dynamic than responsive design because it changes content and functionality, not just layout. It is more immediate than personalization because it responds to current context, not just historical data. Adaptive interfaces can use personalization as one input — your behavioral history — but they also incorporate real-time signals like device state, environment, and inferred goal.

The distinction matters because it affects architecture and design process. A responsive design pattern is largely a front-end CSS concern. Personalization requires user accounts, preference storage, and recommendation algorithms. Adaptive design requires sensors, inference logic, and carefully designed state transitions. Knowing which approach you need helps you scope the work and choose the right technical foundation.

User Goal Adaptation: Designing Around Intent

Of the four dimensions, user goal adaptation is the one I recommend starting with. It produces the biggest usability improvement for the least implementation complexity, because you can often infer goals from simple signals.

The core idea is straightforward: identify the most common user goals in your product, figure out how to detect which one the user is pursuing right now, and adjust the interface to support that goal.

Take a password manager as an example. A user might open a password manager to: (a) log in to a website, (b) create a new password, (c) share a password with a family member, or (d) audit their existing passwords for security issues. These are four very different goals, and they require different layouts, different primary actions, and different information hierarchies.

How do you detect the goal? In this case, contextual signals help. If the user opened the app via autofill from another app, they are almost certainly trying to log in. Show the search bar prominently and the autofill history at the top. If the user navigated directly to the app and it is their first time opening it today, they might be checking for recent security alerts. Surface the security dashboard. If they just created a new account on a website, they might want to save the credentials. Show the save dialog.

The most reliable signal for goal detection is navigation source. Did the user arrive via a deep link, a notification, a bookmark, or by typing the URL directly? Each source implies a different intent. Deep links from a notification about an overdue task suggest a goal of completing that specific task. Typing the URL directly suggests browsing or general awareness. The best adaptive interfaces treat navigation source as a primary input, not an afterthought.

A second powerful signal is recency and frequency. If a user has opened the same document five times in the last hour, they are still working on it. Surface that document, show autosave status, and keep the toolbars and panels optimized for the task they were performing. Do not reset to a generic home screen every time. Google Docs does this well. When you reopen a document you were editing, the cursor is exactly where you left it and the interface state is preserved.

A third signal is time since last visit. A user returning after six months needs a different experience than a daily active user. The returning user might need a re-onboarding prompt, a what-is-new modal, or a simplified interface to jog their memory. The daily user needs speed and shortcuts. I am surprised how few products differentiate between these two scenarios. Most treat a six-month return visitor exactly the same as someone who was using the product fifteen minutes ago.

Environmental Adaptation: Designing for Physical Context

Environmental adaptation addresses the physical realities of where and how people use your product. This is where situational impairment comes into sharp focus.

Ambient light is one of the most impactful environmental variables. A user reading their phone at noon in a sunlit park has a very different visual experience than someone reading the same screen in bed at midnight. Most products handle this with an automatic dark mode based on time of day or sensor data, but the adaptation can go further. In bright conditions, increase contrast ratios, thicken borders, and use solid backgrounds instead of translucent ones. In dark conditions, reduce luminance, use softer shadows, and avoid pure white backgrounds that cause halation. Apple's Night Shift and Android's Bedtime mode are basic steps, but UI elements themselves should adapt, not just the color temperature.

Network quality is another environmental factor that makes a real difference. I frequently test products on slow or intermittent connections, and most of them assume a stable high-speed connection. An adaptive interface degrades gracefully. It loads critical content first and defers non-essential images, animations, and third-party widgets. It shows loading states that communicate progress honestly. It enables offline capabilities where possible. When the network is unavailable, it surfaces a clear explanation and cached content rather than a generic error.

I once worked on a project management tool that was used by construction crews on job sites. The crew members were often in basements or remote areas with poor connectivity. We built an adaptive mode that detected offline status, cached the task list and blueprints locally, and let workers mark tasks as complete offline. When connectivity returned, it synced silently in the background. The adaptation completely transformed adoption on the ground. The crews had been using paper printouts because the web app was unreliable on site. After the adaptive mode launched, paper usage dropped to near zero.

Input modality is a dimension that is becoming more important as devices proliferate. A user interacting with a smart display using voice commands needs different interface patterns than someone tapping on a phone or clicking with a mouse. Adaptive interfaces can detect the current input modality and adjust accordingly. When a user switches from keyboard to touch on a tablet, increase hit targets. When voice input is detected, surface audio feedback and simplify visual options. The operating system provides these signals, and product teams need to respond to them.

Designer reviewing user journey maps and context scenarios on a whiteboard in a modern creative office

Mapping user journeys across different contexts and environments is the foundation of adaptive interface design — what works in one scenario may fail completely in another.

Device Capability Adaptation: Designing Beyond Screen Size

Screen size is the most obvious device characteristic, and responsive design handles it adequately. But modern devices have a lot more going on than just pixels, and ignoring those capabilities means leaving functionality on the table.

Processing power and memory vary enormously across devices. A flagship smartphone from two years ago outperforms many budget laptops. An interface that runs smooth 60fps animations on a high-end device might stutter and feel sluggish on a low-end one. The adaptive approach is to detect device class and adjust animation complexity, data rendering strategies, and background processing accordingly. If a device has limited memory, reduce the number of items rendered in a long list and use virtual scrolling. If the device has a slower processor, simplify transitions and reduce the number of concurrent animations.

I have seen this distinction make a real difference in emerging markets, where mid-range Android devices dominate. Products that perform well on these devices tend to win market share, regardless of feature parity. Google's Adaptive Performance library for Android provides thermal and performance state information that apps can use to adjust their behavior. It is a shame more products do not use it.

Battery level is a surprisingly overlooked adaptation signal. When a device is below 20% battery, users are conserving power. An interface that continues playing auto-playing videos, polling for updates every few seconds, and running expensive animations is actively hurting the user. An adaptive interface reduces background activity, pauses non-essential animations, and switches to simpler rendering modes. Even something as small as reducing the frequency of real-time updates can extend battery life.

Sensor availability determines what interactions are possible. A device with a lidar scanner can support augmented reality features that a device without one cannot. A device with a gyroscope can respond to tilt and rotation. A device without GPS cannot provide location-based features. The adaptive approach is to check sensor availability at runtime and gate features behind capability checks, rather than assuming all devices support all features. This is standard practice for some teams, but I still see products that assume GPS is always available, or that crash when a camera permission is denied.

Storage capacity matters for products that cache content locally. A music streaming app that tries to cache 500MB of offline songs on a device with only 200MB free will fail silently or, worse, crash. An adaptive interface checks available storage before initiating large downloads and surfaces a clear message about space requirements with an option to manage existing cached content.

Behavioral Adaptation: Learning from How Users Actually Behave

Behavioral adaptation is where adaptive interfaces shade into personalization. The difference is that behavioral adaptation focuses on immediate, within-session adjustments rather than long-term profile building.

The simplest form of behavioral adaptation is frequency-based ordering. If a user consistently opens the same three reports every Monday morning, the interface should surface those reports on Monday mornings without being told. This is not machine learning. It is basic pattern recognition backed by reasonable defaults. The interface observes, remembers, and adjusts.

A design team I consulted for built a dashboard product for data analysts. They noticed that analysts had predictable weekly rhythms. Monday was for reviewing the previous week's performance. Tuesday through Thursday was for deep dives and ad hoc queries. Friday was for preparing reports. The team added an adaptive home screen that shifted its layout based on the day of the week and recent activity patterns. Analyst satisfaction scores increased significantly because the product met them where they were instead of showing the same static dashboard every day.

Adaptive defaults are another powerful behavioral pattern. When a user repeatedly selects a non-default option, the interface can learn that preference and update the default. A calendar app that defaults to weekly view but notices the user always switches to monthly view should, after a few repetitions, make monthly view the default. The adaptation should be gradual, not switching after one data point, and easily reversible. Users should never feel trapped by an adaptive default they cannot override.

Adaptive toolbars and menus are common in desktop software. Microsoft Office does this, showing frequently used commands in the primary toolbar while moving infrequently used ones into overflow menus. The pattern works well on desktop where toolbars have ample space, but it is trickier on mobile where every pixel counts. On mobile, I recommend showing only the most critical actions by default and exposing secondary actions through an overflow menu that users can customize. Let the most-used actions float to the surface naturally.

The risk with behavioral adaptation is that it can create a filter bubble in the interface. If the interface only shows the user what they have done before, they may never discover new features or workflows. Good behavioral adaptation balances familiarity with discoverability. Surface the familiar for efficiency, but periodically introduce new options or suggest alternative workflows. Slack does this well with its "Did you know?" tips that appear in context, showing off features the user has not tried yet.

Progressive Disclosure and Adaptive Complexity

Progressive disclosure is one of my favorite UX patterns, and it maps naturally onto adaptive interfaces. The idea is to show only the information and controls a user needs at each step, revealing additional complexity gradually as needed. Adaptive interfaces can take progressive disclosure further by tailoring what gets disclosed to the user's skill level and task context.

Consider a photo editing app. A novice user opening the app for the first time should see basic tools: crop, adjust brightness, apply a filter. An advanced user opening the same app should see curves, layers, masks, and color grading tools. The difference is not about hiding features but about adjusting the default view based on user expertise, which can be inferred from behavior — how often does the user access advanced tools? How long do they spend on each editing step?

This approach, sometimes called adaptive complexity, has been studied in human-computer interaction research. The studies find that adaptive complexity improves satisfaction for both novice and expert users. Novices feel less overwhelmed, and experts feel more productive because they do not have to navigate through simplified interfaces to reach the tools they need.

I recommend implementing adaptive complexity as a three-tier system. Tier one is the simplified view, shown to new users or users performing a focused task. It contains only the essential controls and clear guidance. Tier two is the standard view, shown to regular users in normal contexts. It shows the full feature set with a clean layout. Tier three is the expert view, shown to power users or when the interface detects advanced behavior. It exposes shortcuts, advanced parameters, and customization options.

The transitions between tiers should be smooth and gradual. Never jump a user from tier one to tier three in a single session. Let them opt in to more complexity at their own pace, and always provide a clear path back to the simpler view. I also recommend giving users manual control over their tier, even when the automatic detection works well. Some users prefer simplicity even after years of using a product, and that preference deserves respect.

Design Patterns for Adaptive Interfaces

Over the past several years, a set of reusable design patterns for adaptive interfaces has emerged. Here are the ones I have found most effective in practice.

Pattern 1: The Adaptive Onboarding Funnel

Instead of the same onboarding flow for every user, adapt the onboarding based on user role, team size, and goals captured during signup. A solo freelancer onboarding into a project management tool does not need to see team collaboration features. An enterprise team does not need the same emphasis on personal task management. Segment your onboarding flow and measure conversion at each segment independently.

Pattern 2: Contextual Priority Shifting

Change the priority of interface elements based on inferred user goal. When a user opens a messaging app from a notification about a specific conversation, that conversation should be front and center, not buried behind a generic inbox view. When a user opens a document editor from a link shared by a collaborator, the comment sidebar should be visible because collaboration is the goal.

Pattern 3: Graceful Degradation

Design for constrained conditions first, then enhance for capable conditions. This is progressive enhancement applied to context rather than just browsers. Start with the lowest-bandwidth, smallest-screen, simplest-input version of your interface. Then add layers of enhancement for devices and environments that support them. This ensures your adaptive interface never breaks completely. It just becomes simpler.

Pattern 4: Adaptive Navigation

Adjust navigation structure based on user role, task frequency, and device. A first-time visitor to a content site might see a broad category-based navigation. A returning visitor might see navigation organized by their most-visited sections. A user on mobile might see a bottom tab bar with four actions, while a user on desktop sees a sidebar with ten sections. The navigation adapts to what is most useful for the current context.

Pattern 5: Predictive Action Buttons

Surface the most likely next action based on current context and past behavior. A music app might show "Resume Playing" as the primary button when a user opens it after a pause. A project management app might show "Quick Log Time" when a user opens it on a Friday afternoon. The predictive button reduces cognitive load by guiding the user to the most probable next step.

Pattern 6: Cross-Session State Preservation

Remember not just what the user did, but where they were in a workflow. If a user was filling out a multi-step form and closed the browser, the adaptive interface should restore their progress exactly. If a user was reviewing a document with specific filters applied, those filters should be preserved. This sounds obvious, but I consistently see products reset to default state between sessions, forcing users to reconstruct their context manually.

Common Mistakes Designers Make with Adaptive Interfaces

Adaptive interfaces can go wrong in spectacular ways. I have made most of these mistakes myself, and I want to save you the trouble.

Mistake 1: Making adaptation too aggressive. The single biggest risk of adaptive UIs is that the interface changes too much or too frequently, disorienting the user. A user who sees a completely different home screen every time they log in has no mental model of the product. They cannot develop muscle memory because the interface is unpredictable. The fix is to make adaptations slow, gradual, and bounded. Introduce one change at a time. Keep the overall layout and navigation framework stable. Adapt within familiar structures, not by restructuring the entire interface.

Mistake 2: Not making adaptation reversible. Every adaptive change should be overrideable. If the interface automatically opens a sidebar based on an inferred goal, the user should be able to close that sidebar. If the interface rearranges toolbar buttons based on frequency, the user should be able to pin a specific button to a fixed position. Adaptive interfaces that trap users in their adaptations create frustration and distrust.

Mistake 3: Relying on wrong signals. I once saw a product that tried to detect user mood based on typing speed and scrolling patterns. It was spectacularly wrong — generating useless adaptations that confused users. The problem was that the signal was too noisy and the inference too unreliable. Only use signals that are directly correlated with the adaptation you want to make. A user's search query is a good signal for goal inference. The angle at which they hold their phone is not.

Mistake 4: Ignoring user control over adaptation. Some products go fully automatic with no user-facing settings for adaptive behavior. This is a mistake. Users should understand that adaptation is happening and have some control over it. Provide a settings panel where users can enable or disable specific types of adaptation, adjust sensitivity, and reset their adaptive profile if needed.

Mistake 5: Designing adaptations in isolation from user research. The best adaptive interfaces are grounded in real behavioral data. I have seen teams design elaborate adaptive logic based on assumptions about user behavior that turned out to be false. Test your adaptation hypotheses with real users before implementing them. Use A/B testing to validate that your adaptive changes actually improve metrics like task completion time, error rate, and satisfaction.

Mistake 6: Forgetting to design the transitional state. When an interface adapts mid-session, the transition itself needs design attention. Abrupt changes are jarring. Smooth transitions with appropriate micro-interactions — a subtle animation, a brief highlight, a clear before-and-after state — help users understand that the interface has changed and why. The transition is part of the user experience, not just a technical implementation detail.

Building an Adaptive UI Strategy for Your Product

If you are convinced adaptive interfaces are worth pursuing, here is a process for building your adaptive UI strategy.

Step 1: Audit Your Current Adaptation Opportunities

Review your analytics and user research to identify the most impactful contextual differences in how people use your product. Look for patterns where users take unnecessary steps to adjust the interface to their needs. Common findings include: users who always switch to a particular view, users who consistently perform the same sequence of actions, users who abandon tasks at specific points in the flow, and users who interact with your product in environments you never designed for.

Step 2: Build a Context Matrix

Create a matrix of user contexts mapped against interface states. For each context (user role, device type, time of day, network quality, location, task type), define what the interface should look like, what content it should prioritize, and what interactions it should support. The matrix surfaces contexts that demand contradictory adaptations and helps you prioritize which dimensions to adapt first.

Step 3: Start with Goal Adaptation

User goal adaptation almost always produces the largest improvement for the least complexity. Start by identifying the three most common user goals in your product and designing minimal adaptations that support each one. Measure the impact on task completion and satisfaction before expanding to other dimensions.

Step 4: Implement with Feature Flags and A/B Testing

Treat adaptive features as experiments. Implement each adaptation behind a feature flag. Run A/B tests comparing the adaptive version against the static version. Measure not just engagement metrics but also error rates and support tickets — adaptive interfaces that confuse users often generate more support volume. Only promote adaptations that show clear, positive results.

Step 5: Collect Adaptation Quality Feedback

Build feedback mechanisms that let users tell you when an adaptation was helpful or unhelpful. A simple thumbs up or thumbs down on adaptive changes, with an optional comment field, provides invaluable signal. Over time, you can use this feedback to refine your adaptation logic and identify patterns that work across your user base.

Step 6: Iterate and Extend

Once your initial adaptations are validated, extend them to additional dimensions. Add environmental adaptation by detecting network quality and ambient light. Add device capability adaptation by optimizing for different performance tiers. Add behavioral adaptation by learning from user patterns over multiple sessions. Build your adaptive capabilities incrementally, validating each addition before moving to the next.

The future of interface design is not static screens that we agonize over in Figma and ship as immutable layouts. The future is interfaces that understand their users, respond to their context, and adapt to serve them better with every interaction. Adaptive design is not about making interfaces smarter for the sake of being smart. It is about respecting a basic truth of user experience: every user is different, every moment is different, and every use of your product happens in a unique context that deserves to be acknowledged.

Start small. Pick one dimension, one context, one adaptation. Test it, measure it, iterate on it. The users who benefit will not say "thank you for the adaptive interface." They will not notice it at all. And that is the highest compliment adaptive design can receive.

References

Published by Timothy Graf | GrafWeb CUSO — UX design theory and practice for modern product teams.