.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.”
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?
In 2020, Lennar assembled its Virtual Buying and Selling Teams. The Virtual Selling team was responsible for building and maintaining the Digital Sales Presentation, a platform built to sell homes virtually during the Covid-19 Pandemic. Because the Virtual Buying Online Checkout was seen as more innovative and had more potential for revenue, it was the primary focus of the teams until users became more vocal.
During a down housing market, Lennar corporate advised divisions to cut costs, with one of those costs being external vendors. Lennar divisions operated as their own states, and because the Digital Sales Presentation was not meeting their needs as a sales tool, they sought outside vendors to build them a custom sales presentation. With over 75 divisions, this was over $400,000 in costs per year to build and maintain these platforms. At the same time, because these come out of their individual budgets — nothing is forcing the Divisions to switch. We need to build something they’ll use as though they were an external customer.
Myself and my user researcher flew to Florida to meet with the Florida division who was most vocal about the transition. We observed them selling to homebuyers in a variety of communities — some fully built and almost sold out, others still under construction but with the prospect of outrageous amenities. Because Florida was not able to use the Digital Sales Presentation, some communities used external vendor developed programs to show availability. Others had foam boards with availability and amenities mounted on the wall.
This was the crux of the issue — every community was different, and every division was different — at least, that’s what we were told.
Upon returning we spoke with additional regions who said the same thing — that the way they sell is unique, and that a digital program would need to be customized. But ultimately we found that there were 5 steps that nearly all successful Lennar sales reps took when a prospective homebuyer walked through 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.
Sales reps said that our homes aren’t different from many of our competitors, and focusing on home specs forces the buyer to focus on price. Instead, the sales reps like to focus on the experiential aspects of buying from Lennar.
Based on this feedback we knew the following:
The landing page would be the community video that could act as a screensaver when no one was present. This helps sell the idea of the community. From there, the About Lennar tab is an option for sales reps who want a visual to speak to the size and accomplishments of Lennar.
The nearby tab was created to give sales reps an opportunity to speak to the location. Lennar, being a large homebuilder, has the ability to build in more favorable areas. For those communities that are in more rural or undeveloped areas, sales reps use the map to speak to how Lennar building communities helps areas develop over time. We also built the capability for them to search for distances to specific locations to make sure the tour experience felt personal.
Most importantly, the Community Map showed the full picture of availability for all communities, as well as filtering capabilities to help sales reps quickly filter down to homes that match the buyer’s preferences. From here, they still had the flexibility to do a virtual tour of a home, or drill down into the details to get more specific specs about a certain home.
This experience also included a dynamic Amenities map, a mortgage calculator, a compare feature, and the ability to track a session from start to finish so that a sales rep could then send a recap of their tour to the homebuyer once completed.
The initial rollout was bumpy, but eventually thanks to corporate trainers and regular communication with sales reps, we were able to get adoption across all Divisions. This project laid the groundwork for further development around the sales rep tool ecosystem, allowing sales reps to track leads, tours, and follow ups across all Lennar internal tool touchpoints.
Want to see more?
ShipBob needed to redesign its new business onboarding for its Startup Stella Persona. Stella represented 22% of new revenue in Q2, and 58% of all merchants shipping with ShipBob. Our primary KPI was to increase the Startup Stella’s submitting warehouse receiving orders by 10%, knowing that submission increased likelihood of conversion by 80%.
Startup Stella’s made up a large percentage of ShipBob’s revenue, but the self-service onboarding experience was failing them. The data showed there was an average of 20 days between warehouse receiving order submission and receipt at warehouse, but we knew that 80% of Startup Stellas that create a warehouse receiving order convert to shipping their first order.
I conducted moderated user interviews with real merchants — a first for ShipBob — and combined those findings with support ticket analysis and behavioral data. We knew these users had low business complexity, but little experience with logistics and very little time to spare.
Pricing was confusing, appeared more costly than competitors, and came too late in the flow
The onboarding tasklist included unnecessary steps, industry jargon, and was surrounded by distracting dashboard elements
Merchants who submitted a warehouse receiving order had an 80% conversion rate — but most never got there without help
Increase conversion on new user Sign Up.
Increase number of submitted Warehouse receiving orders.
Decrease number of days to send inventory to ShipBob warehouse.
We first added a qualification step to the flow to aid in the reduction of $10,000 refunds. By asking them what they AREN’T selling, we felt this was an easy way to reduce errors down the road and eventually tailor their experience.
The next step would be integration. This step ultimately was deprioritized due to lack of engineering resources, but when we did unmoderated user testing of these flows, participants said they wanted to understand pricing before they connected.
Lastly, we would show the calculator. We went through several iterations of this page; some with category selectors, others with sliders alluding to custom pricing. This was a major concern as in the scenario a larger merchant went through this flow, they may not know they were eligible for quantity price breaks.
Below is the final price calculator which was a simple box calculator. This option showed all of the different factors that go into pricing at ShipBob; this was important as ShipBob is typically viewed as being more expensive than competitors, when in reality it included many benefits that other competitors upcharged for.
Because we removed so many steps from the dashboard into the onboarding flow, we could use the dashboard to get them where we wanted them to be much faster: adding their products and sending us their inventory. Everything else could be done after the fact, including integrating their store.
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?
