Case study

Portfolio Redesign

Additional information

AI in the Process

How AI supported the Portfolio Redesign from early product thinking through exploration, implementation, testing and refinement while the direction and decisions remained human-led.

Overview

AI changed the workflow, not the responsibility.

For this project, I wanted to explore what an AI-assisted product design workflow could look like when AI was involved from the beginning rather than introduced only during development. I used it across research synthesis, positioning, information architecture, content, visual exploration, implementation and refinement. This allowed ideas to move into tangible outputs much faster. But speed also made judgment more important. Every generated suggestion still needed to be questioned, compared against the project goals and refined within the design system. The process became less linear: Understand → Explore → Create → Evaluate → Refine. Rather than treating these as isolated phases, I could move between them quickly as the product evolved.

01 — Concept

Starting with the problem, not the prompt.

Before asking AI to create anything, I needed to understand what the portfolio needed to accomplish. The challenge was not simply to redesign an outdated website. My work and positioning had evolved, and the portfolio needed to communicate both what I create and how I think. AI became a thinking partner during this stage.

Challenge the problem definition

I used conversations to test whether the initial framing described the real portfolio challenge.

Compare positioning options

Exploring different ways to describe my work helped surface what was distinctive and what felt too generic.

Turn broad thoughts into requirements

AI helped organise ideas and identify gaps, but I decided which audience needs and product goals should shape the experience.

02 — Structure

Turning conversations into a product architecture.

Once the direction became clearer, I used AI to help organise the portfolio as a system rather than a collection of pages. Together, we explored sitemap options, homepage hierarchy, case-study architecture, different levels of content depth, project metadata, reusable section types, navigation behaviour, related case-study pages and responsive behaviour. This contributed to an important architectural decision: the portfolio content should be data-driven and the interface should be composed from reusable patterns. Instead of hard-coding each case study independently, projects could share an underlying content model while still supporting different narratives.

Content and system architecture

03 — Design

Exploring quickly without outsourcing the design decisions.

AI made it possible to explore visual directions quickly, but generated output was treated as material for evaluation rather than a finished design. I used it to explore page compositions, hierarchy, editorial layouts, illustration concepts, visual metaphors, colour relationships, component ideas and responsive possibilities.

Professional but human

The portfolio needed to feel credible without becoming impersonal.

Editorial but approachable

Long-form storytelling needed character while remaining easy to read.

Structured but not rigid

Reusable patterns needed to create clarity without flattening different project narratives.

Distinctive without distraction

Ideas that supported the direction were refined. Others were discarded, even when they looked polished.

04 — System

Turning exploration into constraints.

As the visual direction stabilised, I documented the decisions as a design system. Typography, colour, spacing, layout, interaction patterns, components and illustration principles became shared constraints for both design and implementation. This was particularly important when working with generative tools. Without constraints, AI could produce something plausible but visually inconsistent with the rest of the portfolio. The design system became a reference point for evaluating generated output.

TypographyColourSpacingLayoutIllustration

Explore the Design System →

05 — Visual generation

Prompting became part of the design documentation.

The portfolio illustrations were created with AI, but consistency could not depend on repeatedly asking for something that simply looked similar. I defined a reusable illustration language covering line weight, level of abstraction, colour restraint, negative space, composition, representation of people, shapes and connecting paths, and things to avoid. I then combined three elements: FIXED VISUAL LANGUAGE + VARIABLE SUBJECT BRIEF + EXISTING VISUAL REFERENCE = CONSISTENT ILLUSTRATION FAMILY This transformed prompting from an isolated instruction into a reusable part of the design system. The full illustration documentation lives with the Design System rather than being duplicated here.

06 — Build

Moving into the browser earlier.

One of the biggest changes to my process was reducing the distance between design and implementation. Rather than completing every screen in a separate design environment and handing it over later, I could move progressively into the browser and evaluate decisions in the actual product. AI-assisted coding helped translate the system into reusable React / Next.js components while I remained responsible for the architecture, behaviour and visual quality. The implementation was deliberately structured around reusable components, structured project data, flexible case-study sections, responsive behaviour, accessible interaction patterns, reusable related-page architecture and maintainable design tokens. This meant implementation became another design environment.

07 — Collaboration

Giving AI context before asking it to change the product.

As the codebase grew, maintaining consistency became more important than generating code quickly. I introduced project-level instructions that described how AI should work within the repository. These included expectations around design tokens, component reuse, accessibility, responsive behaviour, data-driven content, naming, project architecture, Git safety, avoiding unnecessary dependencies and inspecting existing code before creating something new. This changed the interaction from: “Build this.” to: “Understand the system first, then propose the smallest appropriate change.” For larger changes, I used an assessment-first workflow. AI would inspect the existing implementation, explain what already existed, propose the change and identify affected files before modifying anything. This gave me an opportunity to review the approach before implementation.

08 — Refine

Fast generation made evaluation more important.

AI reduced the cost of trying alternatives. That meant I could test different layouts, content structures, illustrations and implementation approaches without treating the first solution as precious. But faster iteration also introduced a new risk: accepting something simply because it looked plausible.

Solve the original problem

Does this still support the portfolio goals and audience needs?

Fit the established system

Does it belong with the existing visual language, content model and component patterns?

Work across contexts

Does it remain clear, responsive, accessible and useful in the working product?

Remain worth keeping

Is it simpler than the alternative, reusable where it should be and still recognisably my work?

09 — Judgment

AI generated possibilities. I remained the decision-maker.

AI was useful because it could rapidly generate alternatives, structure information and help translate ideas into implementation. But it could not decide what the portfolio should communicate or whether an output was appropriate simply because it was technically correct.

Frame the problem

I defined what the portfolio needed to accomplish and who it needed to serve.

Establish context and constraints

I provided the positioning, architecture, design system and repository guidance needed to make suggestions relevant.

Evaluate and challenge

I compared alternatives, identified inconsistencies, questioned weak solutions and made the trade-offs.

Maintain the direction

I decided what belonged, what needed refinement and when something was ready.

Reflection

AI made the process faster. Structure made it useful.

The biggest lesson from the project was that better AI output did not come simply from writing longer prompts. It came from creating better context. Clear positioning helped AI reason about content. A defined architecture helped it understand where new features belonged. The design system helped it maintain visual consistency. Reusable components constrained implementation. Repository instructions helped preserve technical decisions. Reviewing proposed changes before implementation helped me stay in control of the product. AI increased the speed at which I could move between thinking and making, but the quality of the result still depended on the clarity of the system surrounding it. The project changed how I think about my role as a designer. I don’t see AI as replacing the design process. I see it as reducing the friction between understanding a problem, exploring an idea and making it tangible. That gives me more opportunities to test my thinking — and places even greater importance on judgment, clarity and intentional decision-making.

Supporting context

The tools were secondary to the workflow.

Different tools supported different parts of the process, but the story is not about the software. It is about how I used conversations, visual references, working code and repository context to move between thinking, designing, building and evaluating while remaining responsible for the outcome.

Tools and working context

ChatGPTClaudeFigmaFigJamCursorOpenCodeGit / GitHubAGENTS.md