.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 experiences 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.
In 2020, Lennar assembled its Virtual Buying and Selling Teams as part of a broader push toward “One Lennar” — an initiative to create a unified experience across a company operating in 75+ largely autonomous markets. Each division had long run its own playbook: different tools, different presentations, different processes for the same product.
The Virtual Selling team owned the Digital Sales Presentation, a platform meant to standardize how reps walked prospective homebuyers through communities, homes, and the Lennar brand. But standardization only works if people use the thing. And reps weren’t.
Divisions weren’t using the Digital Sales Presentation — not because they were told not to, but because it didn’t fit how they actually sold. Some had brought in outside vendors to build custom tools. Others were running tours off foam boards and printed availability sheets. A few were pulling up Google Maps mid-visit.
The problem wasn’t that sales reps were resistant to technology. It was that no one had asked them how they sold. The platform had been built around assumptions, not behavior. We needed to understand what a unified sales experience actually looked like on the ground — and build toward that instead.
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 — whether they knew it or not.
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?
I led the pre- and post-launch design of thinkorswim Web, a new web-based trading platform to pair with the legacy thinkorswim desktop and mobile applications built for active traders, but we wanted it to be friendly enough for those users newer to the active trader space and clients coming from the Schwab acquisition who may be less familiar with the platforms.
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.
I led the design and research for this feature, working alongside a Product Manager and a team of 3 engineers.
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. Here's what we learned:
Many traders didn't know what advanced orders were or how to place them — the existing interface made them feel like the system was trading for them
Users who did place these trades did so almost exclusively on desktop because the mobile interface was too manual and complex
These users mapped to a “swing trader” persona — capturing price movements over hours to weeks, where speed and strategic order configuration were critical
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.
Competitors lacked the depth and complexity that thinkorswim had for active traders (First Image) so there wasn't much inspiration to gather. In an effort to understand what I was building more deeply, I had my Product Manager walk me through exactly what happens with each of these trades, and noticed a pattern. It reminded me of conditional logic.
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 on the left. 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.
Want to see more?
