Erik Lanza's portfolio

Product Designer based in Turku, Finland. I design scalable, system-driven digital products where clarity has to be earned. My work focuses on complex, constraint-heavy environments, where processes, usability, structure, and craft must work together.

From Compliance to Clarity: Designing for CardioSignal

CardioSignal is a regulated mobile health product designed to detect cardiac irregularities using a smartphone. In this context, I encountered several challenges that come with building in a highly regulated environment.

---

• Read more about designing for CardioSignal

skeins — idea to product

Part One: Discovery & Definition

In Part 1, I share how a simple knitting project exposed an unexpected problem with tracking stitch increases, and how that led me to build a small app to help, turning a hobby frustration into a coding project.

---

• Read part one

AI-Assisted Study Case

This workflow reframes how product and design work could be approached using AI help for handling some heavy lifting of requirements gathering, documentation, and initial prototyping. The focus shifts to what matters most, thinking critically, iterating quickly, and making better design decisions earlier.

---

• Read full AI-assisted study case

• Behance
• Email

• Home

AI-Assisted Study Case

Context

I came across an open product design role at Vire Health, a Finnish health-tech startup building a waist-worn circadian health tracker. I decided to apply and treat the application as a real design exercise.

Could I use AI to move through the all stages of a product design process quickly, rigorously, and in a way that produced work I'd actually stand behind?

Spoiler: Yes and no

phase i

Discovery: Understanding the product

Synthesising what the product do

The first step was simple: I asked AI to extract and synthesise the key Vire features from their live product page.

I got a comprehensive result: hardware specs, sensor capabilities, the circadian timing angle, pricing and availability.

phase ii

Definition: Turning insight into product decisions

Building user personas

Now that I understand the product, I can try to understand the users. Based on the product description above, I ask AI for specific, grounded user personas whose needs are rooted in what Vire does.

Jobs To Be Done (JTBD)

With the personas in place, the next step is digging into why these users have this need, and JTBD is the right tool for that.

The JTBD pointed clearly in one direction. For the scope of this case study, I'll focus on the Body Clock view.

phase iii

Ideate: Generating solutions

AI-assisted quick prototyping

To explore solutions, I used AI to first to generate a Product Requirement Document (PRD) from the information gathered previously. Then used that PRD as the blueprint for building a working prototype using AI.

The prototype could be tweaked and improved using AI. I will go on a controversial route and use Figma's MCP server and the AI-generated prototype code to create a script I can import to Figma and generate design frames and layers.

Now I import the script to a Figma file and voilà, we have an arrangement of Figma design layers.

In conclusion

For this case study, the answer to "Could I use AI to move through the all stages of a product design process quickly, rigorously, and in a way that produced work I'd actually stand behind?" is Yes and no. Fast and exploratory? Absolutely. Rigorous? Not on its own. AI can move you through the process quickly and open up options you might not have considered, but it can't replace the humans you're designing for. The resulting design isn't usable as-is, but it's a jumping-off point.

• Home

From Compliance to Clarity: Designing for CardioSignal

Context

CardioSignal is a regulated mobile health product designed to detect cardiac irregularities through short measurement sessions. As a medical device software product, it must comply with IEC 62366-1 usability engineering standards, requiring rigorous validation, documentation, and risk mitigation before release.

challenge i

Scaling a product design library under delivery pressure

Design and development teams were working in silos, recreating components independently and making ad-hoc decisions that slowly deteriorated visual and functional consistency.Without a shared source of truth, fragmentation compounded with every sprint, and delivery pressure meant there was rarely time to stop and fix it. Furthermore a product targeting users aged 50 and above, accessibility had never been considered, leaving a core part of our audience underserved.

To address this, I initiated the creation of a scalable design library built on Atomic Design principles and grounded in Material Design 3 tokens. Accessibility was included in the form of colour contrast, typography scale and not basing design in colour in text only but form.

The Design Library

The colours in CardioSignal’s brand book are primarily light pastel tones intended for brand and marketing use rather than for UI. I based the interface palette on those brand colours but adapted them for digital usability. The updated colours are brighter and provide higher contrast to improve readability, targeting WCAG level AA accessibility. Font sizes were also standardised to ensure consistent typography across the interface.

Iconography

To reduce reliance on colour alone, iconography was given a more prominent role in the interface. This allows colour-blind users to rely on shapes and symbols in addition to colour. The icons reinforce the message while also adding a subtle decorative element to the UI.

From sketch to library: Early hand-drawn explorations helped define simple, recognisable shapes before being refined into consistent UI icons for informational features.

Components

With the foundations in place, the next step was building components. Grounded in the same tokens and principles that defined the library's core, each component could be constructed efficiently and reused across the product, eliminating redundant work and ensuring consistency without sacrificing speed.

Combining these components was where the system truly came alive, yielding a cohesive UI that felt intentional at every level.

challenge ii

Establishing as well documented design process

Designing in a regulated medical context introduces a fundamental tension: every change must be validated, documented, and traceable. In practice, this is difficult to sustain across a cross-functional team, decisions are made in conversations, context gets lost between tools, and what seems clear to a designer rarely arrives intact on a developer's screen.

It was clear that a structured process was needed.

I started by tackling traceability at the handover stage. Figma remained the design tool of choice, but handovers directly from Figma often introduced ambiguity. Having used Zeplin in the past, I reintroduced it as the dedicated handover and specification layer, providing clean, pixel-perfect specs and, crucially, version control that created a reliable audit trail for every design change.

From there, each handover fed directly into Jira, where development tickets were created with the full context needed to implement and validate the work. To close the loop, every handover was walked through in a dedicated design handover call with developers, a space to resolve questions and confirm shared understanding. Once implementation was complete, I reviewed and approved the built solution before it progressed to QA, ensuring that what reached testing was faithful to the validated design intent.

The result was a process that made traceability a natural byproduct of how the team worked, not an extra burden layered on top of it.

Outcome

Over time, the impact became measurable. Design and development cycles grew faster as teams stopped solving the same problems twice. Inconsistencies reaching production decreased, and the cost of future changes dropped significantly. Most importantly, the product became meaningfully more accessible to the people it was built for, older adults who deserve an experience designed with their needs at its core, not bolted on as an afterthought.

• Home

skeins — idea to product

Part One: Discovery & Definition

The problem

One of my hobbies is crochet, but I wanted to take it a step further and try knitting. I came across a scarf pattern that looked interesting and seemed like a simple, approachable way to get started, so I bought it and began knitting.

After a few attempts, I quickly realised it wasn’t as easy as it seemed. The pattern required increasing a stitch every eight rows, and keeping track of both rows and stitches turned out to be more cumbersome than expected.

At first, I used pen and paper to keep count. It worked for a while, but eventually I still lost track. That’s when I thought about building a simple app that could count up to a set number and remind me when it was time to increase. It didn’t seem like it should be too difficult, especially with the current wave of “vibe coding” tools. I built the app using Claude and deployed it online with Vercel and Supabase.

Now that I have a working prototype, I want to apply a more structured design process. My goal is to use this as a starting point and gradually redesign the app using real knowledge and feedback, while mimicking real-life product development scenarios.

I named the app Skeins.

Skeins prototype views

What I set out to understand

Before redesigning anything, I needed to answer two questions: was this a real problem beyond my own experience, and were there already tools solving it?

On the problem, I’m lucky to have my partner sharing the same hobby. His frustration confirmed that this wasn’t just me. Interestingly, his failure point was slightly different. He would lose count mid-row due to distractions, while I tended to lose context after taking a break. Different moments, same underlying issue. No tool was tracking where you were within a cycle. Every workaround simply tracked a number.

YouTube short explaining the same problem and using pen and paper as a solution

Online post listing the best apps for knitting

I also saw the same pattern elsewhere. YouTube videos of knitters working on shaped pieces often show pen-and-paper tally marks as the go-to method. The problem is real and fairly widespread.

On the competition, the market splits neatly into two categories, and both fall short.

All-in-one apps like Knit Companion and My Row Counter are powerful but heavy. They are designed for managing complex PDF patterns over long periods, not for quick cycle tracking during short sessions. On the other end, generic counters like Easy Knitty are fast but limited. They count taps, nothing more.

There is a clear gap. No one seems to be offering cycle-aware tracking in a simple, mobile-first interface.

The competitive gap

Who I'm designing for

Three types of people reach for Skeins:

What they're hiring Skeins to do

The core job

When I return to my knitting after a break, I want to instantly know where I am in the pattern cycle, without having to mentally reconstruct my progress, so I can resume knitting right away.

Everything else is secondary.

The first real finding

Giving the app to my partner was the most valuable step in this phase. He was an ideal test user. Same project, same problem, and motivated to use it. Still, the interface confused him on first use.

Two issues stood out.

Setup

He didn’t know what to enter in the increase interval field because he didn’t know the Sophie Scarf’s interval. The app asked for a number but didn’t explain what that number represented.

Alert timing

After completing row seven, the app told him an increase was due on the next row. He wasn’t sure whether to act immediately or after knitting one more row. The message was technically correct, but unclear.

What this reveals

Both issues point to the same root cause. The app assumes prior knowledge. It expects users to understand knitting concepts and pattern structure before they can use the tool.

UX takeaway

A tool like this cannot rely on user knowledge. It needs to make the underlying concept visible and unambiguous. Inputs should be self-explanatory, and outputs should clearly indicate action. If a user has to interpret meaning, the design has already failed.

Design principles

What’s next

Phase 2 resulted in a clear brief: fix two specific failures, make the interface self-explanatory, and keep the scope tight. No pattern storage, no Ravelry integration, and no features that belong to a different product.

In Part II, I’ll walk through how I translated that brief into design decisions, covering ideation, user testing, and the Figma work that followed.

• Home

skeins — idea to product

Part II: Design Process