.png)
With 10 years of experience working on digital products, I like going where there are problems to solve.
I use data, research, and AI-assisted development to help design products that make strategic impact.
For Industry Leaders and Market Challengers
.png)
It's better to launch something and learn than to wait and debate and never launch anything because you want it to be perfect.
AI is making building things faster and easier than ever. That means it's even more important to listen to users and understand what they actually need.
Users care more if a product solves their problem than if it looks sexy. UI is the icing on the cake.
And anyone that acts like they do is lying. Product development is a game of tradeoffs and the goal is to learn.
I’m Lena, a Chicago native who’s a Texan at heart. After college I started in product but being a natural creative, it wasn’t long before I moved into UX design. I get energy from solving complex business problems and creating simple, intuitive experiences for users.
In my free time I love hunting, cooking, and traveling (to Japan in particular).
“Lena Stefani is the kind of UX designer every team hopes to have—strategic, insightful, and relentlessly focused on improving the user experience. What sets Lena apart is her ability to translate complex research findings into elegant, intuitive design solutions that truly move the needle.”
“Lena has a gift for navigating complex product problems with incredible attention to detail. She doesn’t just design; she facilitates high-level collaboration across the entire organization to ensure the right solution is built. She would be a massive asset to any team.”
“Lena is the kind of designer every product manager hopes to work with—deeply grounded in user research, obsessed with solving the right problems, and consistently able to translate insights into intuitive, high-impact design. She has an exceptional ability to balance user needs with business goals, and she always prioritized speed to value without compromising quality. Whether we were refining early prototypes or launching core product features, Lena was a driving force behind our team’s momentum and success.”
Let’s talk. Drop me a message below.
Message sent! I’ll be in touch soon.
HLRBO is a marketplace that connects hunters with private landowners who lease land for hunting. I worked on Landkey, HLRBO's flagship transaction product designed to turn informal lease conversations into structured, protected, revenue-generating transactions.
The first version of Landkey gave landowners a way to generate contracts, add insurance, run background checks, collect signatures, and accept payment through HLRBO. But adoption was slower than expected because the flow depended on landowners initiating the process. After launch, we reversed the flow — allowing hunters to initiate a lease request and place a deposit — which generated roughly 400 lease requests in a single weekend.
HLRBO helps hunters find private land to lease for hunting. Landowners list their properties, and hunters browse available land, message landowners, tour properties, and eventually lease access.
HLRBO's business model depended on helping those leases happen through the platform. Before Landkey, the marketplace helped users discover each other, but the actual lease process often happened outside the platform — relying on messages, phone calls, paper contracts, offline payments, and separate insurance or background check processes.
HLRBO did not just need to help users find each other. We needed to help them complete the transaction safely, confidently, and through the platform. Landkey became the product that connected all of those steps into one leasing workflow.
We designed for two sides of the marketplace: landowners and hunters.
Landowners controlled the supply — they owned or managed the properties and decided who leased their land. We identified two distinct landowner personas:
Distant or less-engaged landowner leasing land as a low-effort, income-generating asset.
Landowners seeking to offset expenses or generate modest passive income, while maintaining some control over their property.
Hunters brought the demand. They wanted access to quality private land, a fair deal, and the confidence that the property would be theirs before someone else claimed it.
Access to well-maintained private land that matches their hunting style — whether that's whitetail, waterfowl, or upland game.
Urgency-driven. Good land goes fast, and hunters know it. They want to secure a property before the season starts or before someone else does.
Often lease as a group, splitting costs across a hunting club or group of friends. Decisions involve multiple people.
Clear terms, a trustworthy process, and confidence that their money and commitment are protected from the start.
Before designing Landkey, we knew the existing lease process was fragmented and risky for both sides. Users were not just dealing with a clunky digital experience — they were navigating a disjointed real-world transaction with legal, financial, and safety implications.
A typical lease could involve several disconnected steps:
That meant users could discover land on HLRBO but complete the most important part of the transaction somewhere else.
Hunters didn't always know if their payment would actually secure the lease. Landowners didn't always know if a hunter was serious until money changed hands. This created trust issues and weakened the marketplace. If HLRBO wanted to own the transaction, payment needed to feel secure, trackable, and connected to the lease process.
Many leases relied on outdated, incomplete, or informal contracts. Some landowners had their own agreements. Others handled terms through messages. That created risk — hunters and landowners needed a clearer way to define lease terms, responsibilities, dates, rules, payment expectations, and who was allowed on the property.
Hunting leases involve real liability. People are entering private land with weapons, vehicles, equipment, and sometimes groups. Landowners needed confidence that they were protected. Without a structured system, protections were inconsistent. Landkey gave HLRBO a way to bring insurance, background checks, signatures, and payment into one connected process.
HLRBO had already helped hunters and landowners find each other. Landkey needed to help them safely complete the lease. This insight shaped the first version of the product.
The first version of Landkey focused on creating a complete transaction system for hunting leases. The flow allowed a landowner to:
We did not support custom leases in V1 because we wanted as much of the transaction as possible to happen through HLRBO. This kept the flow cleaner and more consistent, but created friction for landowners who already had contracts they trusted.
We required landowners to start the lease because they controlled the property and terms. This preserved landowner authority, but placed the most effort on the least digitally active user.
We allowed primary hunters to add others to the lease without requiring every hunter to subscribe. This reduced friction and protected lease completion, but left a potential revenue opportunity for later.
We used Stripe to keep payments fast, trackable, and connected to the lease workflow. Some landowners preferred checks, but manual payments would have slowed the process and reduced platform visibility.
We added a screen before the actual flow to ask landowners if the lease was already signed. This helped us keep listings more up-to-date and collect data on how many landowners were completing transactions off-platform.
The landowner flow was framed as four steps: create the contract, answer insurance questions, send to the hunter to pay and sign, then return to the landowner for final signature. Technically more than four steps, but grouping them and showing the full picture upfront reduced drop-off by making the process feel manageable before anyone committed.
.png)
With this flow, we introduced a 14% facilitation fee on all listings — similar to how Airbnb surfaces fees to guests. The fee would show to hunters as part of the final price, but we wanted landowners to understand why their public listing price looked different from what they originally entered.
It's common in hunting leases for the hunter to cover the landowner's insurance. This screen showed landowners their coverage and confirmed they pay $0 — framing insurance as a benefit rather than a task. Making the $0 cost explicit was intentional: we wanted landowners to feel protected, not burdened.
We originally placed the Stripe payment connection in the middle of the flow. It became a major drop-off point — many landowners weren't technical, didn't know what Stripe was, and didn't understand why they needed another account. Moving it to the end reduced abandonment while we worked toward a check-based payout option, which was their strongly preferred payment method.
On the hunter side, the first thing a primary leaseholder had to do was add any other hunters to the lease. This ensured all parties were named on the contract and gave the landowner full visibility into who would be on their property.
When the primary leaseholder paid, they saw the lease cost, a processing fee, and insurance if applicable. We later introduced Affirm on this screen — a common complaint from hunters was that leases were too expensive, and installment payments helped address that without reducing landowner earnings.
We built email loops for each stage of the signing process — once one party signed, the next received a notification that it was their turn. After the primary leaseholder paid and signed, additional hunters were emailed to create accounts and sign. The added friction was intentional: building this user base supported our longer-term goal of marketing to group hunters and developing group plan pricing.
After launch, Landkey was completing leases — but not as many as we expected.
That was meaningful progress. Before Landkey, HLRBO had no visibility into whether a lease even happened — deals fell out of the platform into DMs, email chains, and paper contracts. But we knew we were leaving revenue on the table, and we had a hypothesis about why.
From the start, we understood that placing the initiation burden on landowners was our biggest structural risk. Landowners controlled the supply, but they were the hardest users to activate — not always online, not always digitally comfortable, and often managing inbound interest with no real tools.
When we looked at what that actually looked like in practice, the signal was clear. Landowners were receiving hundreds of messages a day. We inventoried those messages and found that the most common one was barely a question at all:
"Is this available?"
That single pattern told us two things. First, hunters had real, active intent — they just had no structured way to act on it. They were reaching out manually because the product gave them nothing better to do. Second, it showed us how much noise a landowner had to filter through just to figure out who was actually serious about leasing.
And availability wasn't the only burden. Landowners were also negotiating terms, managing follow-ups, and tracking conversations across messages — before any formal process had even started. We needed to look more closely at where that friction was coming from and what we could do to reduce it.
The strongest signal came from the demand side. Hunters were already trying to lease properties through messages — they had intent, urgency, and motivation. They just had no structured way to act on it. So we reversed the flow.
Instead of requiring landowners to generate the lease first, we let hunters initiate a lease request:
This preserved landowner control while removing the burden of starting the transaction from scratch.
Hunter-initiated Landkey worked because it aligned the product with existing behavior. We didn't ask hunters to learn something new — we gave structure to what they were already doing manually. The deposit helped separate high-intent hunters from casual inquiries, and moved lease intent out of noisy message threads and into a measurable transaction funnel.
A lease request was not the same as a completed lease — but the spike showed that demand had been there all along. Based on HLRBO's transaction model (14% of lease value + $150 transaction fee), increasing completed leases from 5 to 30 per week could represent an estimated $7K–$21K in incremental weekly revenue depending on lease value. Presented as directional modeling, not confirmed revenue attribution.
Flipping the initiation model addressed the biggest bottleneck, but we also explored ways to reduce the operational burden on landowners more broadly — making more inventory transactable without requiring more effort from the supply side.
We designed a landowner calendar to encourage short-term lease engagement. It helped landowners think about their property as available inventory rather than a static listing, and gave both sides a clearer way to engage around availability.
We extended Landkey to support short-term leases — single-day or weekend hunts — giving landowners a way to monetize their property beyond annual contracts. This opened up a new segment of hunter demand and made more inventory accessible to casual hunters who weren't ready to commit to a full season.
We added a feature that let hunters request a guided walk of a property before committing to a lease. This gave hesitant hunters a lower-stakes way to engage, and gave landowners a qualified lead — someone willing to invest time before signing anything.
We allowed landowners to upload their own contracts, reducing friction for those who already had trusted legal language. This was especially important for hunting clubs, who made up a large percentage of our land listings and typically operated under their own long-standing agreements. Supporting their existing contracts was key to retaining that inventory on the platform. A deliberate tradeoff: we sacrificed some standardization in exchange for broader adoption.
We built an AI-generated Q&A module that surfaced common questions and answers directly on property listings. Hunters could get answers about access, rules, amenities, and availability without messaging the landowner — reducing inbound noise and helping hunters self-qualify before reaching out.
Landkey started as a product to make hunting leases safer and more structured. It addressed real problems: insecure payments, inconsistent contracts, limited protections, and a disjointed transaction process.
But the first version taught us that solving the right problem is not enough. The workflow also has to match how users naturally behave. We originally designed around the user who owned the property. But the marketplace showed us that the user with the most intent was the hunter.
We also learned that product problems rarely have a single point of failure. Landowner disengagement wasn't just about a clunky flow — it was a compounding set of friction points: too many unqualified messages, no visibility into availability, no flexibility around contract formats, no low-stakes way to evaluate a hunter before committing. Addressing any one of those in isolation wouldn't have moved the needle. We had to think in systems — identifying the full landscape of friction and designing solutions that worked together to make landowners more reachable, more confident, and more willing to transact through the platform.
The person with authority is not always the right person to initiate the workflow. And a single fix is rarely enough — the most durable solutions address the system, not just the symptom.
Want to see more?
Lennar’s “One Lennar” initiative set out to unify the virtual buying and selling experience across 75+ markets. I led UX design, strategy, and research for the Digital Sales Presentation — a platform designed to give every Lennar sales rep a consistent, polished way to take a prospective homebuyer from first impression to final decision. The goal wasn’t adoption by mandate. It was to build something reps would genuinely choose over the tools they were already using.
Lennar is one of the largest homebuilders in America, building and selling over 80,000 homes each year. In 2020, Lennar hired an outside agency to build their Digital Sales Presentation tool — a platform designed to bridge the gap during the pandemic, when sales reps were unable to show homes in person.
However, as the pandemic passed and sales reps were back to showing homes in-person, their usage of the Digital Sales Presentation dwindled.
As the product designer on the Virtual Selling team that owned this platform, it was my job to understand why. We met regularly with division representatives to gather feedback on the platform. In one of those meetings, a sales representative told us that the platform did a poor job representing the Lennar sales method.
That comment changed the trajectory of our work on the product moving forward.
The existing Digital Sales Presentation was built around exactly that — being a digital sales presentation. Based on high-level feedback, we knew we needed additional features to make it more useful outside of the pandemic era, like community maps. But even as we shipped those improvements, adoption remained low.
We were often told we would struggle to make progress because “each division sold differently.” Lennar was unique in its organizational structure in that it was similar to the United States; Lennar corporate built products and gave directives on company goals, but each individual division and region were like states that had their own funding, marketing teams, and ways of working.
Our goal became to build a standardized sales presentation that scaled to fit the needs of 75 divisions across Lennar.
The users of the Digital Sales Presentation were Lennar’s NHCs — New Home Consultants. They were not realtors, but sales people trained specifically to sell Lennar homes. Some had previously worked in real estate, but many others had simply excelled in customer-facing roles and brought a natural ability to connect with people.
We learned that in a fast housing market, Lennar hired an influx of NHCs that they were not able to train at scale. This contributed to confusion around the product and disjointed sales processes.
Formerly a teller at their local bank, Casey became a Lennar NHC after being referred by a friend. She now lives in a Lennar community herself, and enjoys helping families find their dream home.
My researcher and I flew to Florida to observe the division most vocal about the gap. We sat alongside sales reps as they walked homebuyers through communities — some nearly sold out, others still under construction. We watched them navigate between external vendor tools, foam boards, and printed availability sheets to cobble together a coherent presentation on the fly.
Every division insisted their approach was unique. After speaking with additional regions, we heard the same thing everywhere — that their market was different, their buyers were different, their communities were different. And they weren’t wrong about any of that.
But underneath the variation, we found a pattern. Nearly every successful Lennar sales rep followed the same core sequence when a buyer walked in the door.
The proven sales method
Make a Friend
You’re not selling — you’re getting to know them. Understand their needs and what’s bringing them in.
Start Big, Zero In
Narrow from the big picture down to the personal.
Show the Home
Show Good, Better, and Best — never more than 3 homes. By now, they already know.
“Our homes aren’t different from many of our competitors. If you focus on home specs, the buyer focuses on price. We sell the experience of buying from Lennar.”
This shaped everything we built. Two principles guided the design:
We structured the platform around the proven sales sequence. The entry point was a community video — immersive enough to act as a screensaver when no one was in the room, and strong enough to set the tone when a buyer walked in. From there, the About Lennar tab gave reps a visual anchor to speak to the scale and credibility of the builder before getting into community specifics.
The Nearby tab let reps speak to location in context — a critical piece for communities in areas still developing. Reps could search driving distances to specific landmarks, keeping the tour personal and grounded in the buyer’s actual life.
The Community Map was the centerpiece. It showed full availability across all communities with filtering so reps could zero in on homes matching the buyer’s priorities — and drill into virtual tours or detailed specs from the same view. No tab-switching, no foam boards.
The platform also included a dynamic amenities map, a mortgage calculator, a compare feature, and session tracking — so reps could send buyers a personalized recap of everything they’d seen together once the tour was over.
Rollout required close partnership with sales trainers to get reps comfortable with the new flow. But because the platform reflected how reps already worked — rather than asking them to change — adoption took hold across divisions. The DSP became the foundation for a broader sales rep ecosystem, eventually connecting lead tracking, tour history, and follow-up workflows across Lennar’s internal tools.
Every division told us their market was unique. And they were right — the communities were different, the buyers were different, the competitive context was different. The mistake would have been to dismiss that and push a one-size-fits-all solution.
What research revealed was that the variation was real, but it was mostly surface-level. Underneath it, reps were already doing the same things in the same order — they just didn’t have a shared language for it, and they certainly didn’t have a tool built around it.
The platform succeeded because it reflected how reps already sold, rather than asking them to sell differently. “One Lennar” wasn’t achieved by mandating uniformity — it was achieved by finding what was already uniform and building something that honored it.
You don’t standardize by telling people to be the same. You find what’s already common and give it structure.
Want to see more?
ShipBob’s Growth Team identified a critical activation gap: merchants who submitted a warehouse receiving order converted at 80% — but most never got there without help. The self-service onboarding was failing the people who drove the most revenue. I led UX design, strategy, and research on a full onboarding redesign that increased warehouse receiving order creation by 24%, improved overall conversion by 20%, and cut the average time to send inventory by a third.
ShipBob’s Startup Stella persona — small merchants with straightforward logistics needs and very little time to spare — represented 22% of new revenue in Q2 and 58% of all active merchants on the platform. Getting Stella to submit a warehouse receiving order (WRO) was the single most important activation moment in the onboarding flow. Merchants who submitted a WRO converted to shipping their first order at 80%. The problem was that most never got there on their own.
The Growth Team set a target of increasing WRO submission by 10%. What we found in research suggested the gap wasn’t a motivation problem — it was a design problem.
The redesign was scoped to ShipBob’s Startup Stella persona — the merchant segment that made up the majority of the platform and whose activation behavior made them the highest-leverage target for onboarding improvement.
Early-stage merchant with straightforward product lines and big growth ambitions, but little time, little logistics experience, and a tight budget. Stella isn’t looking for a logistics partner with every feature — she needs one that gets her up and running fast without making her feel like she needs a manual.
The data told a clear story. On average, it took 33 days from sign-up to a merchant sending their first inventory shipment — time the business couldn’t afford to lose. Nearly a third of all support tickets were basic account setup questions, meaning the onboarding was generating ongoing operational cost. Pricing confusion alone accounted for 16% of tickets, and ShipBob was issuing over $10,000 in refunds for inventory that arrived unshippable because merchants hadn’t been properly qualified upfront.
I conducted moderated user interviews with real merchants — a first for ShipBob — and layered those findings with support ticket analysis and behavioral data. The picture that emerged was consistent: Startup Stellas weren’t disengaged, they were lost.
Pricing appeared more expensive than competitors and surfaced too late — after merchants had already invested time in setup
The onboarding checklist was cluttered with unnecessary steps, logistics jargon, and surrounded by a dashboard that pulled attention in every direction
The 80% WRO conversion rate was sitting behind a wall that most merchants couldn’t clear alone
Three problem areas drove the redesign strategy. Each required a different kind of intervention — some in the sign-up flow, some in the onboarding checklist, and some in how ShipBob communicated value.
The sign-up form was losing people before they even got started. We added social proof and a clear value proposition to set expectations early, and stripped out redundant fields that created unnecessary friction at the door.
The onboarding checklist had too many steps, too much jargon, and no clear sense of progress. We removed non-essential steps, added a product qualification gate to reduce unshippable inventory, and prioritized the actions that moved merchants toward activation.
Pricing confusion was one of the biggest sources of drop-off and support tickets. We moved pricing earlier in the flow and redesigned the calculator to make ShipBob’s actual value proposition legible — including the bundled benefits that made it competitive with lower-priced alternatives.
The first addition was a qualification step at the top of the onboarding flow. By asking merchants what they weren’t selling before they got any further, we could flag incompatible inventory types early — reducing refunds downstream and laying the foundation for a more tailored experience over time.
Next was the integration step. Though it was ultimately deprioritized due to engineering constraints, unmoderated testing surfaced a meaningful insight: merchants wanted to understand pricing before they connected their store. That finding directly shaped how we sequenced the rest of the flow.
The pricing calculator went through several rounds of iteration — category selectors, sliders, tiered displays. The challenge was communicating a nuanced pricing model without overwhelming small merchants, while still making sure larger merchants understood they qualified for volume breaks. The final version was a transparent breakdown of every cost factor — making ShipBob’s bundled value legible against competitors who charged extra for the same services.
With steps moved out of the dashboard and into the onboarding flow, the post-sign-up experience could focus entirely on activation: adding products and sending inventory. Everything else could follow once merchants were live.
First iteration of the qualification step. We asked merchants upfront what they weren’t selling to flag restricted inventory types before they invested time in setup — reducing downstream refunds and creating a hook for personalization later.
Second iteration refined the framing and reduced visual noise. The goal was to make this feel like a quick, helpful screen rather than a gate — something that set the merchant up for a better experience rather than slowing them down.
First iteration of the store integration step. Though this was eventually deprioritized due to engineering constraints, testing this screen revealed that merchants wanted to see pricing before connecting their store — a finding that reshaped the entire flow sequence.
Second iteration of the integration step, refined based on usability feedback. Even in its deprioritized state, the research from this screen had lasting impact on how we ordered the rest of the onboarding experience.
Early calculator iteration using category selectors. The challenge was making a nuanced pricing model scannable without dumbing it down — and making sure larger merchants could still see they were eligible for volume discounts.
Slider-based iteration. This version felt more interactive but tested poorly — merchants found sliders less trustworthy than fixed inputs when dealing with something as concrete as fulfillment costs.
The final calculator: a transparent, line-item breakdown of every cost factor. ShipBob was often perceived as more expensive than competitors — this screen made the bundled value visible, showing that many services others upcharged for were already included.
The redesigned post-sign-up dashboard. By moving account setup steps into the onboarding flow, the dashboard could focus on the two actions that drove activation: adding products and sending inventory. Everything else — store integration, advanced configuration — followed after merchants were live.
Some work was pushed outside of scope due to a shift in engineering resources. The project also established the value of moderated user research at ShipBob — making the case for a practice that had not previously existed on the team.
Want to see more?
The ability to place "advanced orders" is a feature that allows active traders to place trades that trigger or cancel future trades, or place multiple trades at once. These trades accounted for 1% of trades overall but were placed by some of our most lucrative traders.
Advanced traders visiting the platform were consistently requesting some variation of these advanced orders since launch. This was a way to drive more trading revenue through the platform, as well as provide feature parity with Schwab platforms and an accessible solution for advanced orders for thinkorswim users.
thinkorswim web was the web-based companion to the thinkorswim desktop and mobile apps. With desktop and mobile being heavy, data-dense platforms, the web-based platform faced an opportunity to be a lighter, usability-friendly, and accessible version that people could use at work. Prior to its launch, we worked to add features on a weekly basis so that the platform could reach parity with its predecessors.
Advanced orders — trades that trigger or cancel future trades — accounted for just 1% of all trades, but were placed by the platform's most lucrative traders. These power users had been requesting the feature since launch, and the platform needed it for both compliance and competitive parity. We opted to build this before other requested features given this, as well as the fact that markets were volatile and other features were bottlenecked due to engineering constraints.
This feature also had the potential to increase trades, assuming the end result was more options or futures contracts. This meant more revenue being generated from the platform.
I conducted user research with active traders and internal employees to understand how they thought about advanced order types. I wanted to learn if and how users were interacting with this feature on our existing platforms, and what their mindset was around placing these types of trades.
They did not know what they were or how to place one.
It did not fit their trading style.
They did not trust the system to place their trade correctly.
💡 While we couldn’t change whether it fit their trading style, we could provide more clarity to help them understand how these orders worked and build trust in the system.
Swing traders who needed advanced orders to automate their trading strategies used these to capture quick price movements. Movements may take place as quickly as intraday, or sometimes over the course of 1–2 weeks. These types of order builds occur within what we called the “Strategize” step of the journey as the user is gauging the level of risk they're willing to take on before submitting their trade.
Speed is of the utmost importance.
Trying to capture price movements based on charts & market volatility.
Decision occurs is assessing risk levels during “strategize” step of path.
Movements may take place as quickly as intraday, or over the course of 1–2 weeks.
.png)
Easy to understand relationships between trades.
Great for novice traders.
Too manual for core user base to quickly place trades.
thinkorswim Web had the opportunity to bridge the gap between platforms by optimizing for both speed and clarity.
Because thinkorswim is one of the most powerful trading platforms on the market, it was difficult to look for inspiration directly from competitors. Most only had a few of these “advanced orders”, and therefore didn’t have a UI capable of the necessary complexity. One competitor, WeBull, had 4 types of orders that could be controlled by toggle. While internal employees told me this was a smooth experience, it still was not scalable to thinkorswim’s capabilities.
After competitors fell short, I knew I had to think outside the box for a solution. In order to do this, I knew I had to understand these trades more deeply. I worked with my product owner to understand each of the different trades. In writing all of them down, I began to notice a pattern. WHEN order 1 gets placed… THEN, Order 2a OR Order 2b gets placed. I began to notice a pattern that reminded me of conditional logic that spanned across each of the trade types.
After I found this pattern, I went on the hunt for inspiration outside of the brokerage industry. I found sleek UI’s for condition builders, and found one experience that included a toggle, not just as a way to control the conditions, but also as a way to show relationships between the items it was connecting.
I took inspiration from the conditional logic builder to build this toggle into the trade ticket. My assumption was that it was quick enough for an advanced user to toggle between different order types, but provided clarity to newer users about what the relationships were between the different trades they'd be placing.
After sharing the first iteration internally, I received feedback that it wasn't clear what the relationship was between the trades, and that the buy/sell wasn't clear enough given the colors and the ability to remove trades (via the checkbox). That led me to the second iteration on the right, where I removed the checkboxes, added color and text to indicate the buy and sell legs of the trade, and centered the toggle with “connected” to make the toggle more prominent.
“This one is pretty simple to follow. It’s just the logical conditions to put in what happens — what are the conditions based on triggering the next order. So, if I want the subsequent orders to only be considered when the buy order triggers, I would hit “THEN”. And then on the two sell orders, I guess the “AND” option wouldn’t apply, unless I have a different type of order. If the question is do I understand what this does, then yes, it’s pretty self-explanatory.”
The feedback in user interviews was overwhelmingly positive, with users both experienced and novice stating that the toggles we had them use helped them understand the purpose and relationships between the trades.
Once we validated the concept, I continued to make concepts for edge cases like the one seen below. While it was an edge case, our platform was primarily built for option traders. This solution was not only flexible enough to accommodate option trades, but also could be integrated with other order types we'd be adding down the line.
While we did not have robust reporting in place to quantify advanced trade usage, the launch was still a meaningful step forward for thinkorswim Web. It closed a key feature gap between web and desktop, expanded what active traders could accomplish without switching platforms, and reinforced our broader product strategy: bringing the power of desktop trading into a faster, more accessible web experience. The result was a complex trading workflow redesigned into an experience that felt approachable enough for newer advanced traders, while still preserving the control and flexibility experienced traders expected from thinkorswim.
Want to see more?
Great for advanced power users who want to get in and out of trades quickly.
Intimidating for new users and other types of traders to understand and locate.