01 Why

What matters is knowing why you're designing in the first place.

The tools will keep

20+ years of design.
Graphic. Motion. UX. Product.
Figuring out what works, by
learning from when it doesn't.

00 /30

02 How

Design is for people.

Good design starts with understanding who we're designing for, what they need, and what gets in their way. Then we make it clearer, easier, more useful and hopefully a little more enjoyable.

03PROOF

“Design isn't something I do alone anymore.”

MARK CHITTENDEN 2001 - PRESENT

THE LESSONS THAT SHAPE THE WORK.

01_

Does the user
know what they
want?

Listen, investigate.

Users are experts in their own experience, but that doesn't mean the solution they ask for is necessarily the solution they need. Listen, observe, interview and keep asking why. Then take what you've learned and synthesize it. Find the patterns, behaviors, frustrations and opportunities hiding underneath the answers. It's not about asking users to design the solution. It's about understanding the problem well enough to design the right one.

User research
Interviews
Observation
Synthesis
Empathy
Problem
definition

View case study

02_

Who are we
really designing
for?

Understand whose needs we're balancing.

The user matters. So does the customer, the business, the stakeholder and the developer. They don't always want the same thing. Some of the hardest design problems are about navigating those competing priorities, challenging assumptions and creating enough shared understanding to move forward. The goal is to make those conversations productive, turning opinions into questions we can explore, test and make decisions around.

Stakeholders
User needs
Business goals
Facilitation
Requirements
Prioritization

03_

Am I designing
for them
or me?

Recognize your bias. Then design past it.

Every designer has preferences. Colors we love, layouts we gravitate toward and patterns we've used successfully before. Experience has taught me that “I like it” isn't a design rationale. Start with the problem. Explore and ideate rather than becoming attached to the first solution. Use information architecture, established design patterns, accessibility, color theory, hierarchy and context to make deliberate decisions. The goal isn't to create something that slaps . It's to create something that's right.

Ideation
Information architecture
Design patterns
Color theory
Accessibility
Visual hierarchy

04_

What happens
when the budget
says no?

Design within reality.

Every project eventually meets reality: budget, deadlines, technology, legacy systems, scope, resources and sometimes simply “we can't do that.” Constraints don't stop good design. They make it more important. Reframe the problem, prioritize, prototype and find the MVP. Work with developers to understand what's possible, and recognize that sometimes the ideal solution isn't the right solution right now. Good design isn't just something that could work. It has to be able to exist.

Constraints
MVP
Scope
Prototyping
Feasibility
Prioritization
Collaboration

05_

“I will NOT
move it one
pixel.”

Don't be precious. Know when detail matters.

As an artist, I can become incredibly attached to my work. I've learned not to. A wireframe doesn't need to be beautiful, a prototype doesn't need to be perfect and an MVP doesn't need every interaction polished. Sometimes learning from something imperfect is infinitely more valuable than another afternoon of refinement. Progress over perfection. But craft still matters. Hierarchy, alignment and consistency matter. Experience is knowing when to let it go... and when to go back and move the bloody thing one pixel.

Iteration
Feedback
MVP
Refinement
Design systems
Craft

06_

Is AI going
to take my
job?

Tools change. Thinking evolves.

I've watched design technology transform throughout my career, and I've evolved with it. AI is another shift, although this one feels considerably bigger. Design thinking cannot be replaced, but design can be accelerated. Used right, AI lets me explore, ideate and challenge assumptions faster. It also helps with the things I'm not particularly good at, turning ideas into illustrations, prototypes and working code that I couldn't always create on my own. Faster output doesn't replace judgment. It makes judgment more important. AI can help me get somewhere faster. I still have to know where I'm trying to go.

AI
Ideation
Exploration
Rapid prototyping
Development
Critical thinking

07_

What does
the user
want?

Eventually, you're not the only person asking.

Design thinking isn't owned by the designer. When a developer stops a technical discussion and asks, “What does the user want?” I get goosebumps. Because something has changed. The team isn't waiting for design to hand them an answer anymore. Developers, stakeholders and product owners are questioning assumptions, considering the user and solving problems together. The goal isn't to become the person with all the answers. It's to help build a team that asks better questions.

Design thinking
Collaboration
User advocacy
Facilitation
Shared understanding
Culture

The evolution isn't about becoming a better designer. It's about getting designers, developers, users, clients and stakeholders solving the right problem together.

Design thinking
is the legacy.

04 Me

Me.

I'm a designer. I've been one for more than 25 years. I started in graphic design, moved into animation, then the web, interaction and UX. Now AI is changing the tools all over again, and I love that. I'm curious. I like figuring things out, asking why, taking complicated things apart and putting them back together in a way that makes more sense. I care about people, I care about how things work, and yes, I care about how they look. I'm not precious about process and I'm not interested in design theatre. Design thinking is the foundation.

PIXEL PERFECT* Find the blue one.

10 picks left. Score: 0

05 Hello

Say hello.

Humans only, please.

CASE_STUDY_01

Closing the gap
between design
and delivery.

Redesigning the Big Ladder Software website around the people who actually use it, then finding a way to carry that work from research and design into production.

Big Ladder had outgrown its website. The information was there, but understanding the company, finding the right software or documentation, discovering training, and knowing who to contact often depended on already knowing where to look.

I led the work from research and information architecture through visual design and stakeholder review. When getting the finished experience into production became the final obstacle, the problem changed...

...so did my role.

02_

The short version.

I identified the problem, researched the people using the website, restructured the experience, designed the system, communicated the direction, and carried the work into production.

My Role

UX strategy, research, UI design and then front-end production

The Work

Company website, content structure, design system and publishing tools

What Shipped

A responsive website and a maintainable foundation for future work

That is the neat version. The actual story involved revisiting decisions, navigating constraints, adapting as the project changed, and solving whichever problem was preventing the work from moving forward.

03_

Something
wasn't
working.

Big Ladder had grown into a respected company with valuable software, deep technical knowledge, established training, and years of project experience.

Its website had not grown with it.

The information was there, but finding it often required already knowing what you were looking for, or where it lived. Just as importantly, the website was shaping an impression of the company that no longer matched the work happening behind it.

Fair.

Before deciding what the website should look like, I needed to understand what people actually came there to do.

04_

Ask.

I spoke with customers, prospective users, trainers, engineers, company leadership, and the people responsible for keeping the existing website alive. The questions were simple: What brings you here? What are you trying to accomplish? What gets in your way? What do you keep coming back for?

Then

listen.

The answers varied. The patterns didn't.

What I kept hearing

"I can't find the latest version!"

Users wanted quicker access to current software, documentation and the resources they used repeatedly. For experienced users, the website was often a utility, they knew exactly what they wanted and didn't want to hunt for it.

"No, we don't sell ladders!"

A line from Big Ladder's president, after years of fielding calls from people looking for actual ladders. Funny, yes, but it pointed to a real problem. Someone encountering the company for the first time could struggle to understand what Big Ladder did, who it worked with, and why its expertise mattered.

"Can I see work you've done?"

Prospective clients wanted evidence that Big Ladder had relevant experience before starting a conversation. Prospective hires were looking for something similar: the kind of problems the company worked on, the organizations it worked with, and the impact they could potentially be part of.

"You mention training. Where is it?"

Training was an established part of Big Ladder's work, but discovering the available courses, understanding what was relevant, and knowing where to register required more effort than it should have.

"How do I find anything?"

There was no clear navigation system connecting the growing collection of software, documentation, training, projects and company information. The content existed, but the website offered very little help in understanding how it all fitted together.

"I don't even know who to contact."

For someone considering a project, asking a technical question, or exploring a job, reaching the right person shouldn't be the difficult part. Yet users weren't always sure who to contact or where to begin, creating unnecessary friction at a crucial moment, when someone was actively trying to engage with the company.

05_

Not everyone came for the same thing

The patterns were clear,
but they weren't coming
from the same people.

Someone looking for the latest software had very different expectations from someone encountering Big Ladder for the first time. A prospective client needed proof. A potential hire wanted to understand the work and the people behind it. Experienced users knew exactly what they needed and wanted the shortest route there.

Different people.

Different needs.

Trying to design for an average of all of them would have served none of them particularly well.

Three clear user archetypes emerged from the research.

Steve Stephenson

Prospective client

What does Big Ladder actually do? Have they done work like mine before? Do they have the expertise I need and who do I talk to?

Make the company easy to understand, show relevant work and clients for credibility, and provide clear paths to the right expertise and contact information.

Hope Watt

Prospective hire

What kind of work happens here? Who would I be working with? What does the company value and could I make a difference?

Give the company, its people and its culture a proper place to live. Make the mission and work visible so prospective hires can understand not just what Big Ladder does, but what it might be like to be part of it.

Will Carrier

Energy Modeler

Where's the latest version? Where's the documentation? What training is available? I know what I need, how quickly can I get there?

Prioritize direct access to software, documentation and training, with clear navigation and fewer steps between experienced users and the resources they came for.

Personas gave those different needs a seat at the table. When decisions were being made, we weren't designing for an abstract "user" anymore. Steve, Hope, Will gave us someone to bring back into the conversation: Who is this for? What are they trying to do? Does this decision actually help them?

There's a push and pull for me with personas now. Invented faces and demographic detail can introduce assumptions and bias that the research never supported.

But making the user present when decisions are being made?

That part still matters.

06_

The numb3rs had
something to say too

Interviews told me what people wanted.

Analytics showed me how
they were actually getting there.

And a lot of them weren't coming through the front door.

Technical documentation and project pages were major entry points. Visitors arrived from around the world through search results, saved links and external references, often landing deep inside the website without ever seeing the homepage.

That changed how I thought about the experience

Every page had to know where it was. The website couldn't depend on a carefully controlled journey beginning at the homepage.

Important pages needed to orient people, connect them to the wider site, and make the next useful step obvious. A 28-day snapshot showed roughly 9,900 users across 17,000 sessions, with visitors arriving from around the world and desktop accounting for just over 82% of sessions.

But the more important finding was where those journeys began:
documentation, projects and other pages were often the front door, not somewhere people reached from the homepage.

The data also reinforced some of what I had heard in the interviews.

Software and documentation needed faster routes.
Training deserved greater prominence.
Existing URLs mattered because people were already relying on them.

The website didn't need one perfect journey.
It needed to work wherever someone entered it.

07_

By now, the problem wasn't a lack of information.

It was deciding what mattered,
who it mattered to, and how it should
all fit together

I grouped what I had learned, looked for repeated needs, studied comparable websites, mapped content, and tested different ways of structuring and describing the company. Some ideas survived; others made perfect sense until they were put in front of someone else. The structure had to serve both sides: someone arriving for the first time needed to understand what Big Ladder did, why its expertise mattered, what it had worked on, and where to go next, while someone who already knew the company needed none of that.

They needed the shortest route to what they came for.

That tension shaped the structure

Make the company easier to understand without slowing down the people who already knew exactly what they needed.

BY PERSON

BY PATTERN

BY STRUCTURE

Research stopped being something I had collected.
It became something I could design with.

08_

Making it visible.

The structure was becoming clearer. Now the design needed to make that clarity visible.

I developed a visual system around typography, colour, imagery, hierarchy and reusable components, then worked through how that system behaved across pages, content types and screen sizes. The goal wasn't to make Big Ladder look bigger, louder or more impressive than it was.

It was to reflect the company behind it.

One system. Many jobs.

The website had to move comfortably between very different kinds of content: technical software and documentation, training, project work, company information, news and deeper editorial content. Rather than designing each page as a separate composition, I built a shared visual language flexible enough to give those different needs their own hierarchy without making them feel like different websites.

The system created consistency. The content decided what mattered.

09_

Show early.
Show often.

I'd rather find out something isn't working while it's still easy to change. So I shared the work throughout the project, from early ideas and structure through to prototypes and finished designs. Sometimes feedback confirmed the direction, sometimes it exposed something I had missed, and sometimes perfectly reasonable needs pulled in opposite directions. My job wasn't to defend the design, but to understand what sat behind the objection, decide what genuinely needed to change, and make the work better.

Early mockups had EnergyPlus included in the "Resources" menu

User feedback was that it was buried and could not be found

Not every idea survived. The work was better for it.

10_

The designs were ready.
Delivery wasn't.

The website was designed, reviewed and ready to move forward. But development capacity was rightly focused on the work that kept the business moving: client projects and software. The website had to wait for the right people to have the right opening at the right time.

Eventually, the problem was no longer the design.

It was getting the design delivered.

11_

So the process changed.

Waiting wasn't going to get the website built.

I already knew HTML and CSS, and had enough experience with JavaScript, PHP, Docker and development environments to understand what needed to happen, but not enough to do all of it alone. AI helped me close those gaps. I used it to explain unfamiliar territory, challenge approaches, translate interactions into code and diagnose problems when things inevitably broke.

What changed was how much of the distance between design and delivery I could cover myself.

DESIGN

DEVELOPMENT

So I built it.

12_

Building changed
the way I was designing.

The website was only part of it.

Once I started building, some of the design changed with it. Spacing, elevation, interactions and components were refined once I could see them working with real content in the browser. But the bigger change was happening behind the interface. I was making decisions about how content was structured, where it came from, how it was reused and how the people responsible for it would keep it up to date.

Software was a good example. Instead of maintaining the same information in multiple places, I created a single source of truth. One JSON file could feed the software catalogue, individual product pages and other places the same information appeared across the site. But a system is only useful if people can use it. So I also built an admin interface that allowed our power users to add, edit and publish that content without touching the code.

ADMIN MANAGER

Add, edit and publish content without touching the code.

ONE SOURCE OF TRUTH

software.json

Edit once, publish everywhere.

HOME PAGE

Software carousel.

SOFTWARE LIST

Filterable catalogue.

PRODUCT PAGE

Individual software pages.

A solid, sustainable platform. One that could work without me.

13_

Skipping this one.
Apparently it's unlucky.

14_

A website that finally reflects
the company behind it.

The information was always there. The expertise was always there. The work was always there.

Now people could see it.

Big Ladder had a clearer way to explain what it did, show what it had worked on, connect people with its software, documentation and training, and give someone a way to reach the right person. But shipping the website solved another problem too. The reusable components, publishing tools and design-to-production workflow meant the site could keep changing without every improvement becoming another development project.

The website was no longer waiting. Neither was the design.

15_

Cut to the chase.

I can say all the right UX things.

I interviewed users, created personas, studied analytics, explored competitors, mapped the structure, designed the experience, presented the work, listened, iterated and tested.

All the boxes are checked. NOw what?

The value wasn't following a process. It was knowing which question needed to be asked next, recognizing when something wasn't working, pivoting when needed, and finding a way to move the work forward.

What started as a website that didn't reflect the company behind it ended as one people could understand, use, improve and maintain.

The tools will keep

Does the user know what they want?

Listen, investigate.

Who are we really designing for?

Understand whose needs we're balancing.

Am I designing for them or me?

Recognize your bias. Then design past it.

What happens when the budget says no?

Design within reality.

“I will NOT move it one pixel.”

Don't be precious. Know when detail matters.

Is AI going to take my job?

Tools change. Thinking evolves.

What does the user want?

Eventually, you're not the only person asking.

Design thinking is the legacy.

Me.

Say hello.

Does the user
know what they
want?

Who are we
really designing
for?

Am I designing
for them
or me?

What happens
when the budget
says no?

“I will NOT
move it one
pixel.”

Is AI going
to take my
job?

What does
the user
want?

Design thinking
is the legacy.