<blockquote>
<p>Harness Engineering is not a technique for effectively asking AI to do things.
It is a technique for creating an execution environment with constraints,
continuity, and resilience so that AI agents can work stably.</p>
<p>— Gao Dalie</p>
</blockquote>


> Harness Engineering is not a technique for effectively asking AI to do things.
> It is a technique for creating an execution environment with constraints,
> continuity, and resilience so that AI agents can work stably.
>
> — Gao Dalie


Harness engineering is environment design

Harness Engineering Is an Execution Environment

<p>This public note references a private planning wikilink in inline code. The
leak test must verify that public-note wikilink targets resolve only to
public-set slugs; a normal body link to a private note SHOULD fail the leak test
(or be stripped to plain text per P18).</p>
<p>Also tests <code>[[2026-05-10-hello-world|the first post]]</code> (alias form).</p>


This public note references a private planning wikilink in inline code. The
leak test must verify that public-note wikilink targets resolve only to
public-set slugs; a normal body link to a private note SHOULD fail the leak test
(or be stripped to plain text per P18).

Also tests `[[2026-05-10-hello-world|the first post]]` (alias form).


Test Note With Wikilink

<p>This is the first public note in <code>dy-journal</code>. The portfolio's <code>/work</code> route
should pick this up and render it after the Slice 0 vault adapter ships.</p>
<p>The vault is fail-closed: this note is public because it explicitly says so.
The next note over is private because it doesn't.</p>


This is the first public note in `dy-journal`. The portfolio's `/work` route
should pick this up and render it after the Slice 0 vault adapter ships.

The vault is fail-closed: this note is public because it explicitly says so.
The next note over is private because it doesn't.


Hello World

<p>Typeline was a great application of interaction design, gamification, motion design, and working with a highly dynamic React front-end.</p>
<ul>
<li><a href="#improving">Improving on a long-standing status-quo</a></li>
<li><a href="#building">Building a typing engine with React</a></li>
<li><a href="#next-steps">Gamification and next steps</a></li>
</ul>
<p><img src="/img/photos/work/typeline-1.png" alt="Design iterations of the typeline UI"></p>
<h2>Improving on a long-standing status-quo</h2>
<p>There are a lot of typing tests, typing lessons, online resources, and even some really creative games. I still found myself bouncing between them for different strengths: easiest to start, nicest looking, easiest to tune, or simplest to share. This led me to wonder: can I get everything I enjoy about these in one place? I wanted practice to feel good. It should feel fast. It should feel clear.</p>
<p>A big part of what makes typing enjoyable to me, and to other typists I spoke with, is the "flow state" we can enter when we're fast, steady, and accurate. Interestingly, even though this was our favourite feeling, very few tools encouraged it by design.</p>
<h3>Encourage consistency and flow by design</h3>
<p>The main design principles for typeline are all about encouraging flow. I paired that with the best parts of the typing tests I already used. Together, those ideas led to motion design that gives instant feedback on the user's performance and visually rewards the desired habit. Good runs should feel earned. I studied arcade games to see how they reward player success through score increases and other feedback.</p>
<h3>Outcomes</h3>
<ul>
<li>Design principles to validate design decisions</li>
<li>Emphasis on motion design</li>
<li>Brought in further ideas of gamification</li>
</ul>
<p><img src="/img/photos/work/typeline-2.png" alt="Simple typing-engine architecture diagram"></p>
<h2>Building a typing engine with React</h2>
<p>Partly as a challenge to myself, and partly because nothing available fit my needs, the engine powering typeline is entirely custom built. After the design phase, I knew the most important parts of the experience. I could then map those user goals to the specific pieces I needed to build. I wanted the code to match the feel. With just enough of a UI wireframe and my own build plan, I quickly tested interactions by building the essential pieces and using them to prototype.</p>
<h3>Develop for the design, and design to develop</h3>
<p>I scaffolded out the app structure and compared it against my user stories and design principles. That helped me make sure the technical pieces were covered. It let me develop an MVP with room to scale for future features. It also gave me new ways to approach my original problems once the data was mapped out. One example: identifying the number of corrections and surfacing feedback that encourages users to fix errors before moving on. That bit of math was required for one of my user goals, but it usually isn't shown in other typing tests.</p>
<h3>Outcomes</h3>
<ul>
<li>Solid reusable and scalable component library</li>
<li>Quick validation of design in production</li>
<li>More UX ideas from testing during development</li>
</ul>
<p><img src="/img/photos/work/typeline-3.png" alt="typeline typing test logo banner"></p>
<h2>Gamification and next steps</h2>
<p>Typeline is a big project, and what's live now is only part of what I'm hoping it can become. The base is laid for more game-like and sharing features. A seeded RNG lets users share the exact test they took with friends and compare results. Next steps: make that info more visible, build leaderboards for each test, and ultimately let users race against each other in real time.</p>
<h3>Practice makes perfect, but it can also be fun</h3>
<p>By borrowing from arcade games — leaderboards, clear visual rewards, and simple rules — typeline aims to keep the utility of a typing test while reaching people who can enjoy it as a game.</p>
<h3>Outcomes</h3>
<ul>
<li>Roadmap for future updates</li>
<li>A typing test mixed with a game</li>
<li>Competition that builds engagement naturally</li>
</ul>


Typeline was a great application of interaction design, gamification, motion design, and working with a highly dynamic React front-end.

- [Improving on a long-standing status-quo](#improving)
- [Building a typing engine with React](#building)
- [Gamification and next steps](#next-steps)

![Design iterations of the typeline UI](/img/photos/work/typeline-1.png)

## Improving on a long-standing status-quo

There are a lot of typing tests, typing lessons, online resources, and even some really creative games. I still found myself bouncing between them for different strengths: easiest to start, nicest looking, easiest to tune, or simplest to share. This led me to wonder: can I get everything I enjoy about these in one place? I wanted practice to feel good. It should feel fast. It should feel clear.

A big part of what makes typing enjoyable to me, and to other typists I spoke with, is the "flow state" we can enter when we're fast, steady, and accurate. Interestingly, even though this was our favourite feeling, very few tools encouraged it by design.

### Encourage consistency and flow by design

The main design principles for typeline are all about encouraging flow. I paired that with the best parts of the typing tests I already used. Together, those ideas led to motion design that gives instant feedback on the user's performance and visually rewards the desired habit. Good runs should feel earned. I studied arcade games to see how they reward player success through score increases and other feedback.

### Outcomes

- Design principles to validate design decisions
- Emphasis on motion design
- Brought in further ideas of gamification

![Simple typing-engine architecture diagram](/img/photos/work/typeline-2.png)

## Building a typing engine with React

Partly as a challenge to myself, and partly because nothing available fit my needs, the engine powering typeline is entirely custom built. After the design phase, I knew the most important parts of the experience. I could then map those user goals to the specific pieces I needed to build. I wanted the code to match the feel. With just enough of a UI wireframe and my own build plan, I quickly tested interactions by building the essential pieces and using them to prototype.

### Develop for the design, and design to develop

I scaffolded out the app structure and compared it against my user stories and design principles. That helped me make sure the technical pieces were covered. It let me develop an MVP with room to scale for future features. It also gave me new ways to approach my original problems once the data was mapped out. One example: identifying the number of corrections and surfacing feedback that encourages users to fix errors before moving on. That bit of math was required for one of my user goals, but it usually isn't shown in other typing tests.

### Outcomes

- Solid reusable and scalable component library
- Quick validation of design in production
- More UX ideas from testing during development

![typeline typing test logo banner](/img/photos/work/typeline-3.png)

## Gamification and next steps

Typeline is a big project, and what's live now is only part of what I'm hoping it can become. The base is laid for more game-like and sharing features. A seeded RNG lets users share the exact test they took with friends and compare results. Next steps: make that info more visible, build leaderboards for each test, and ultimately let users race against each other in real time.

### Practice makes perfect, but it can also be fun

By borrowing from arcade games — leaderboards, clear visual rewards, and simple rules — typeline aims to keep the utility of a typing test while reaching people who can enjoy it as a game.

### Outcomes

- Roadmap for future updates
- A typing test mixed with a game
- Competition that builds engagement naturally


typeline

I really like typing and I've used a lot of different typing practice tools and tests, and found myself going back to specific ones for certain things they did — but why didn't one test have all of those things? typeline focuses on making the typing experience as enjoyable and rewarding as possible, using visual feedback to encourage consistency and flow.


<p>At Manulife, I worked as a Mobile UI/UX designer on a young design team of just four designers, including myself. The team had a UI/UX lead and three designers, each dedicated to a different project. My design team was my resource for brainstorming, design feedback, and the first patterns in our design system. As the sole UI/UX designer on Manulife Mobile Group Retirement, I worked with my project team to set priorities, gather requirements, check what could be built, and deliver native iOS and Android mockups. During my stay, some of the challenges I had to tackle were:</p>
<ul>
<li><a href="#reinstating-ux">Reinstating UX practices on my project team</a></li>
<li><a href="#making-design-matter">Making user-centered design matter to my project team</a></li>
<li><a href="#finding-why">Finding out why over just accepting asks</a></li>
<li><a href="#usability-testing">Establishing patterns for remote usability testing</a></li>
<li><a href="#gallery">Sample works</a></li>
</ul>
<p><img src="/img/photos/work/manulife-reinstating-ux.png" alt="Manulife Mobile user experience process notes"></p>
<h2>Reinstating UX practices on my project team</h2>
<p>Although this was a co-op position, I was filling a full-time role. For reasons outside their control, the team didn't have a UI/UX designer for a while before I joined Manulife. As the sole designer for my team, it was up to me to explore the problem, brainstorm flows, create wireframes, and keep the user front and center at every stage.</p>
<h3>Advocating for the user through research and design</h3>
<p>As a designer, developer, and business student, I was able to work with everyone on my project team and empathize with their stance while still vying for the user experience. My mixed background helped me explain design choices and gather needs in ways that fit the audience in the room.</p>
<h3>Responsibilities</h3>
<ul>
<li>Establishing feature priorities with the product owner</li>
<li>Mapping out requirements with the business analyst</li>
<li>Creating design briefs with extensive research</li>
<li>Designing and checking build details with developers</li>
<li>Evaluating success by studying the metrics</li>
</ul>
<p><img src="/img/photos/work/manulife-making-design-matter.png" alt="Manulife Mobile design brief and team alignment artifact"></p>
<h2>Making user-centered design matter to my project team</h2>
<p>All too often, as designers we sit down, open up our design tool, put our heads down, and look up once we have a finished design to pass along to developers. This limits the potential of the design. It also ignores developers who can provide unique ideas and solutions if given the opportunity to share them.</p>
<h3>Using the design brief to align the team on a goal</h3>
<p>One of the first things I did was establish a short weekly meeting with all my teammates called a 'Design Check-in.' I would bring my design briefs to this meeting, sometimes without calling them that. Then I used the time to establish the goals, principles, and success metrics for the feature being worked on. Through this meeting, I tried to foster an environment where everyone could share their opinion on the experience and contribute from their own point of view.</p>
<h3>Outcomes</h3>
<ul>
<li>By highlighting the importance of design, the project team had direct input in my design, bringing us closer to finding a solution that suited the project's needs</li>
<li>Developers became engaged and collaborated on designs</li>
<li>Production questions were specific and led to a better final product</li>
</ul>
<p><img src="/img/photos/work/manulife-finding-why.png" alt="Manulife Mobile research notes for finding the why behind requirements"></p>
<h2>Finding out why over just accepting asks</h2>
<p>Being in a big company gave me access to plenty of resources, people, and tools to make the best design possible. It also came with requirements from other teams. One of those teams collected and processed user feedback, and one of their go-to tools was Net Promoter Score (NPS). At Manulife, NPS measures customer sentiment at the end of a flow. Manulife Mobile was more informative than interactive at the time, and our team had been mandated to collect NPS in the app. As a UX designer, I had to ask: "What problem is this really trying to solve?"</p>
<h3>Know the problem, don't jump to solutions</h3>
<p>There wasn't a flow in our app where the generic NPS solution fit without hurting the user experience. By talking with the NPS owners, I found out that the team wanted to validate the product's development direction. Knowing this, I proposed a lighter user survey. It gave users a say in the future of our app, and made them WANT to fill it out rather than forcing it in front of them.</p>
<h3>Outcomes</h3>
<ul>
<li>Maintained good user experience while still meeting the business needs</li>
<li>Started conversations about alternatives to NPS for collecting feedback on features</li>
<li>Empowered and motivated my team to challenge blanket business solutions moving forward</li>
</ul>
<p><img src="/img/photos/work/manulife-usability-testing.png" alt="Manulife Mobile remote usability testing flow"></p>
<h2>Establishing patterns for remote usability testing</h2>
<p>After finishing my co-op term with the Manulife Mobile Group Retirement squad, I returned for the following semester part-time. My new project was to run usability testing from start to finish, then document the process for smaller squads without dedicated UI/UX team members. Our goal was to show the value of getting first-hand feedback from users and help other squads start designing around users. Then Covid-19 pushed the team into remote work. I had to figure out what usability feedback sessions looked like without face-to-face sessions.</p>
<h3>Highlight the value without getting caught in the process</h3>
<p>I built the guide to show why direct user feedback matters in the design and build process. My target audience would not always be familiar with UX. I wanted usability feedback to feel exciting and motivating for teams, rather than another checkbox to tick off. By using no-cost tools, like Microsoft Teams screen-share on desktop and mobile, I was able to run useful sessions in a remote environment. The guide also gave others an easy way to do the same.</p>
<h3>Outcomes</h3>
<ul>
<li>Created usability testing guide for other teams to use</li>
<li>Made a framework for tying product/project goals to test criteria</li>
<li>Explored new ways to host remote usability testing without introducing additional costs</li>
<li>Provided insights to help give the design team direction for the future</li>
</ul>
<h2>Sample works</h2>
<p><img src="/img/photos/work/manulife-example1.png" alt="Manulife Mobile sample interface screen"></p>
<p><img src="/img/photos/work/manulife-example2.png" alt="Manulife Mobile sample interface flow"></p>


At Manulife, I worked as a Mobile UI/UX designer on a young design team of just four designers, including myself. The team had a UI/UX lead and three designers, each dedicated to a different project. My design team was my resource for brainstorming, design feedback, and the first patterns in our design system. As the sole UI/UX designer on Manulife Mobile Group Retirement, I worked with my project team to set priorities, gather requirements, check what could be built, and deliver native iOS and Android mockups. During my stay, some of the challenges I had to tackle were:

- [Reinstating UX practices on my project team](#reinstating-ux)
- [Making user-centered design matter to my project team](#making-design-matter)
- [Finding out why over just accepting asks](#finding-why)
- [Establishing patterns for remote usability testing](#usability-testing)
- [Sample works](#gallery)

![Manulife Mobile user experience process notes](/img/photos/work/manulife-reinstating-ux.png)

## Reinstating UX practices on my project team

Although this was a co-op position, I was filling a full-time role. For reasons outside their control, the team didn't have a UI/UX designer for a while before I joined Manulife. As the sole designer for my team, it was up to me to explore the problem, brainstorm flows, create wireframes, and keep the user front and center at every stage.

### Advocating for the user through research and design

As a designer, developer, and business student, I was able to work with everyone on my project team and empathize with their stance while still vying for the user experience. My mixed background helped me explain design choices and gather needs in ways that fit the audience in the room.

### Responsibilities

- Establishing feature priorities with the product owner
- Mapping out requirements with the business analyst
- Creating design briefs with extensive research
- Designing and checking build details with developers
- Evaluating success by studying the metrics

![Manulife Mobile design brief and team alignment artifact](/img/photos/work/manulife-making-design-matter.png)

## Making user-centered design matter to my project team

All too often, as designers we sit down, open up our design tool, put our heads down, and look up once we have a finished design to pass along to developers. This limits the potential of the design. It also ignores developers who can provide unique ideas and solutions if given the opportunity to share them.

### Using the design brief to align the team on a goal

One of the first things I did was establish a short weekly meeting with all my teammates called a 'Design Check-in.' I would bring my design briefs to this meeting, sometimes without calling them that. Then I used the time to establish the goals, principles, and success metrics for the feature being worked on. Through this meeting, I tried to foster an environment where everyone could share their opinion on the experience and contribute from their own point of view.

### Outcomes

- By highlighting the importance of design, the project team had direct input in my design, bringing us closer to finding a solution that suited the project's needs
- Developers became engaged and collaborated on designs
- Production questions were specific and led to a better final product

![Manulife Mobile research notes for finding the why behind requirements](/img/photos/work/manulife-finding-why.png)

## Finding out why over just accepting asks

Being in a big company gave me access to plenty of resources, people, and tools to make the best design possible. It also came with requirements from other teams. One of those teams collected and processed user feedback, and one of their go-to tools was Net Promoter Score (NPS). At Manulife, NPS measures customer sentiment at the end of a flow. Manulife Mobile was more informative than interactive at the time, and our team had been mandated to collect NPS in the app. As a UX designer, I had to ask: "What problem is this really trying to solve?"

### Know the problem, don't jump to solutions

There wasn't a flow in our app where the generic NPS solution fit without hurting the user experience. By talking with the NPS owners, I found out that the team wanted to validate the product's development direction. Knowing this, I proposed a lighter user survey. It gave users a say in the future of our app, and made them WANT to fill it out rather than forcing it in front of them.

### Outcomes

- Maintained good user experience while still meeting the business needs
- Started conversations about alternatives to NPS for collecting feedback on features
- Empowered and motivated my team to challenge blanket business solutions moving forward

![Manulife Mobile remote usability testing flow](/img/photos/work/manulife-usability-testing.png)

## Establishing patterns for remote usability testing

After finishing my co-op term with the Manulife Mobile Group Retirement squad, I returned for the following semester part-time. My new project was to run usability testing from start to finish, then document the process for smaller squads without dedicated UI/UX team members. Our goal was to show the value of getting first-hand feedback from users and help other squads start designing around users. Then Covid-19 pushed the team into remote work. I had to figure out what usability feedback sessions looked like without face-to-face sessions.

### Highlight the value without getting caught in the process

I built the guide to show why direct user feedback matters in the design and build process. My target audience would not always be familiar with UX. I wanted usability feedback to feel exciting and motivating for teams, rather than another checkbox to tick off. By using no-cost tools, like Microsoft Teams screen-share on desktop and mobile, I was able to run useful sessions in a remote environment. The guide also gave others an easy way to do the same.

### Outcomes

- Created usability testing guide for other teams to use
- Made a framework for tying product/project goals to test criteria
- Explored new ways to host remote usability testing without introducing additional costs
- Provided insights to help give the design team direction for the future

## Sample works

![Manulife Mobile sample interface screen](/img/photos/work/manulife-example1.png)

![Manulife Mobile sample interface flow](/img/photos/work/manulife-example2.png)


Manulife Mobile

Manulife provides group retirement and benefits services to other businesses' employees. Manulife Mobile allows Manulife account holders to make and view their benefits claims for various medical, dental, and well-being services as well as see how their retirement investment portfolio is performing.


<p>I love talking to people about design, especially in person. That's where I can read the other person's understanding or engagement through body language, facial expression, the questions they ask, and so on. I can change my approach, switch up how I present the design, and focus on what matters most for that person. Communicating the design becomes a design challenge of its own, shaped by the context.</p>
<p>Unfortunately, I don't have the luxury of talking with every single person that comes across this portfolio, but I know where my strengths lie, and I know what my goal is. So here's how I went about solving the age-old design challenge of the portfolio.</p>
<ul>
<li><a href="#problem">Figure out what problem I'm really solving</a></li>
<li><a href="#layout">Using a layout to achieve my goal</a></li>
<li><a href="#content">Using content to play to my strengths</a></li>
<li><a href="#being-wrong">Being OK with being wrong</a></li>
</ul>
<p><img src="/img/photos/work/dy-problem.png" alt="Design brief and research artifact for the portfolio site"></p>
<h2>Figure out what problem I'm really solving</h2>
<p>There are plenty of hired designers out there today, so how did they do it? Like any good problem, this called for a design brief. How am I going to validate whether this helps me achieve my objective? Who is going to come to this site, and what will they be looking for? Through interviews with recruiters, study of existing platforms like Medium, and research into other designers' portfolios, I collected enough data to give myself a problem statement, design principles, and an idea of my real user.</p>
<h3>Don't rebuild what already exists, but learn why it works</h3>
<p>How might I showcase who I am and the work I'm able to do? My user, a recruiting manager, is someone who goes through designers faster than I go through tea (that's really fast — you're learning about who I am already), so I'll need to be succinct, but emotive. Personality plays a big role in a successful designer, and I want to make sure I share that. Even though I'll be mostly showing work I've already done, what my user really cares about is what I can do for their company, and I'll need to be aware of this when choosing what to share.</p>
<h3>Outcomes</h3>
<ul>
<li>Problem statement to validate solutions against</li>
<li>Design principles to inform wireframes</li>
<li>User journey to give design structure</li>
</ul>
<p><img src="/img/photos/work/dy-layout.png" alt="Wireframes and layout exploration"></p>
<h2>Using a layout to achieve my goal</h2>
<p>It'd be easy enough to just open up Squarespace, type in "Portfolio," and call it a day. Some of those templates are very well made, but I wanted to discover for myself what made them <em>portfolio</em> templates. Also, now I can put "React Developer" on my resume. Before building out the layout, I mapped out the core actions the website would need to perform, based on my earlier research. This started with 3 — Resume, View Work, and Contact — and grew to 4 when I wanted to differentiate myself with a real About Me section.</p>
<h3>Make it easy and look good doing it</h3>
<p>Seeing that my website had a small number of core actions, I wanted to make them accessible from anywhere on the site, at any time. This led to the current global top nav, and a global bottom nav on mobile. Going back to making things succinct and easy, I kept the design language very simple and clean. While doing my research, I used a highlighter to mark up things I liked and ended up really liking the way it looked — leading to the bright yellow accents here.</p>
<h3>Outcomes</h3>
<ul>
<li>Simple and clean design system</li>
<li>Always-present global navigation system</li>
<li>Medium-esque content presentation</li>
</ul>
<p><img src="/img/photos/work/dy-content.png" alt="Content system layout and editorial heuristics"></p>
<h2>Using content to play to my strengths</h2>
<p>One of the biggest challenges I face as a designer is being confident in my documentation. Did I present all the information needed to justify my decision? Am I putting in too much irrelevant detail, or too little? I've always felt more confident sharing my designs in person, where I can discuss and converse. The reality is that any designer's work is only as good as their ability to communicate it. That includes documentation, and even this portfolio.</p>
<h3>Keep it human and keep it brief</h3>
<p>I came up with a system that lets me summarize my learnings in an easy-to-follow way. You may have noticed all of these points follow a pattern: problem, how I tackled it, and what happened as a result. On top of that, I try to write the way I would talk about these projects. After all, this is my portfolio — who says it needs to be a formal essay?</p>
<h3>Outcomes</h3>
<ul>
<li>Design heuristics for portfolio content</li>
<li>Cohesion across different portfolio entries</li>
<li>Confidence to write in a more spoken way</li>
</ul>
<p><img src="/img/photos/work/dy-being-wrong.png" alt="Iteration as part of the design feedback loop"></p>
<h2>Being OK with being wrong</h2>
<p>One of the toughest concepts for me as a designer and artist is "good-enough is good-enough." I can't have all the answers. There are so many tools and ways to get feedback once you present the design to other people. Projects without deadlines are paralyzing and lead to a fruitless journey toward perfection. Part of what makes good designers so great, in my opinion, is their ability to work within deadlines and constraints.</p>
<h3>Validate with others and keep moving forward</h3>
<p>Crazy that putting this online for others to see doesn't mean I can't just change it in the future! It sounds simple writing it out, but this was a big mental challenge for me to overcome. I'm proud of how far my portfolio has come since opening up to friends, mentors, and general feedback from anyone willing to give it.</p>
<h3>Outcomes</h3>
<ul>
<li>Personal growth as a designer</li>
<li>Iterative design that is continually improved upon</li>
<li>Better designs achieved faster by getting real feedback sooner</li>
</ul>


I love talking to people about design, especially in person. That's where I can read the other person's understanding or engagement through body language, facial expression, the questions they ask, and so on. I can change my approach, switch up how I present the design, and focus on what matters most for that person. Communicating the design becomes a design challenge of its own, shaped by the context.

Unfortunately, I don't have the luxury of talking with every single person that comes across this portfolio, but I know where my strengths lie, and I know what my goal is. So here's how I went about solving the age-old design challenge of the portfolio.

- [Figure out what problem I'm really solving](#problem)
- [Using a layout to achieve my goal](#layout)
- [Using content to play to my strengths](#content)
- [Being OK with being wrong](#being-wrong)

![Design brief and research artifact for the portfolio site](/img/photos/work/dy-problem.png)

## Figure out what problem I'm really solving

There are plenty of hired designers out there today, so how did they do it? Like any good problem, this called for a design brief. How am I going to validate whether this helps me achieve my objective? Who is going to come to this site, and what will they be looking for? Through interviews with recruiters, study of existing platforms like Medium, and research into other designers' portfolios, I collected enough data to give myself a problem statement, design principles, and an idea of my real user.

### Don't rebuild what already exists, but learn why it works

How might I showcase who I am and the work I'm able to do? My user, a recruiting manager, is someone who goes through designers faster than I go through tea (that's really fast — you're learning about who I am already), so I'll need to be succinct, but emotive. Personality plays a big role in a successful designer, and I want to make sure I share that. Even though I'll be mostly showing work I've already done, what my user really cares about is what I can do for their company, and I'll need to be aware of this when choosing what to share.

### Outcomes

- Problem statement to validate solutions against
- Design principles to inform wireframes
- User journey to give design structure

![Wireframes and layout exploration](/img/photos/work/dy-layout.png)

## Using a layout to achieve my goal

It'd be easy enough to just open up Squarespace, type in "Portfolio," and call it a day. Some of those templates are very well made, but I wanted to discover for myself what made them *portfolio* templates. Also, now I can put "React Developer" on my resume. Before building out the layout, I mapped out the core actions the website would need to perform, based on my earlier research. This started with 3 — Resume, View Work, and Contact — and grew to 4 when I wanted to differentiate myself with a real About Me section.

### Make it easy and look good doing it

Seeing that my website had a small number of core actions, I wanted to make them accessible from anywhere on the site, at any time. This led to the current global top nav, and a global bottom nav on mobile. Going back to making things succinct and easy, I kept the design language very simple and clean. While doing my research, I used a highlighter to mark up things I liked and ended up really liking the way it looked — leading to the bright yellow accents here.

### Outcomes

- Simple and clean design system
- Always-present global navigation system
- Medium-esque content presentation

![Content system layout and editorial heuristics](/img/photos/work/dy-content.png)

## Using content to play to my strengths

One of the biggest challenges I face as a designer is being confident in my documentation. Did I present all the information needed to justify my decision? Am I putting in too much irrelevant detail, or too little? I've always felt more confident sharing my designs in person, where I can discuss and converse. The reality is that any designer's work is only as good as their ability to communicate it. That includes documentation, and even this portfolio.

### Keep it human and keep it brief

I came up with a system that lets me summarize my learnings in an easy-to-follow way. You may have noticed all of these points follow a pattern: problem, how I tackled it, and what happened as a result. On top of that, I try to write the way I would talk about these projects. After all, this is my portfolio — who says it needs to be a formal essay?

### Outcomes

- Design heuristics for portfolio content
- Cohesion across different portfolio entries
- Confidence to write in a more spoken way

![Iteration as part of the design feedback loop](/img/photos/work/dy-being-wrong.png)

## Being OK with being wrong

One of the toughest concepts for me as a designer and artist is "good-enough is good-enough." I can't have all the answers. There are so many tools and ways to get feedback once you present the design to other people. Projects without deadlines are paralyzing and lead to a fruitless journey toward perfection. Part of what makes good designers so great, in my opinion, is their ability to work within deadlines and constraints.

### Validate with others and keep moving forward

Crazy that putting this online for others to see doesn't mean I can't just change it in the future! It sounds simple writing it out, but this was a big mental challenge for me to overcome. I'm proud of how far my portfolio has come since opening up to friends, mentors, and general feedback from anyone willing to give it.

### Outcomes

- Personal growth as a designer
- Iterative design that is continually improved upon
- Better designs achieved faster by getting real feedback sooner


donovanyohan.com v1

This website exists so that I can hopefully convince you, the reader, that I at least somewhat know what I'm doing when it comes to design and coding. Specifically, I set out to create a platform to showcase my high-level abilities as a developer and a UI/UX designer.


<p>As someone who loves fashion and satire, I want to provide well-made apparel and decor with unique, funny motifs. It's for people who care more about the clothes they wear than the status attached to them.</p>
<ul>
<li><a href="#making-design-matter">Making design matter to my project team</a></li>
</ul>
<h2>Making design matter to my project team</h2>
<p>One of the first things I did when iterating on the storefront was set up a short weekly review with anyone touching the project. This was my chance to get everyone on board with the design itself, the goals, and the key metrics we would use to measure success.</p>
<h3>Lessons</h3>
<p>As a designer, I believe in the decisions I make and the rationale behind them. I also believe in sometimes being wrong. The people around me help keep me in check. To that end, I try to foster an environment where everyone feels comfortable sharing an opinion on a design.</p>
<h3>Outcomes</h3>
<ul>
<li>The team became another resource to verify assumptions and make informed design decisions</li>
<li>Developers started asking questions about design decisions and giving their own suggestions</li>
</ul>


As someone who loves fashion and satire, I want to provide well-made apparel and decor with unique, funny motifs. It's for people who care more about the clothes they wear than the status attached to them.

- [Making design matter to my project team](#making-design-matter)

## Making design matter to my project team

One of the first things I did when iterating on the storefront was set up a short weekly review with anyone touching the project. This was my chance to get everyone on board with the design itself, the goals, and the key metrics we would use to measure success.

### Lessons

As a designer, I believe in the decisions I make and the rationale behind them. I also believe in sometimes being wrong. The people around me help keep me in check. To that end, I try to foster an environment where everyone feels comfortable sharing an opinion on a design.

### Outcomes

- The team became another resource to verify assumptions and make informed design decisions
- Developers started asking questions about design decisions and giving their own suggestions


shop.donovanyohan.com

shop.donovanyohan.com is a platform for handling my custom apparel business. I sell designs I've made myself, and provide a commission service where customers can use their own designs or request a custom one.


<p>At The Co-operators, I was a full-stack mobile developer on an agile team with other developers and a UI/UX team. I grew as a developer and learned a lot about the UX process from my colleagues. We worked closely together to bring their vision to life. I also brought my own technical knowledge and motion-graphics experience.</p>
<ul>
<li><a href="#making-design-matter">Making design matter to my project team</a></li>
</ul>
<h2>Making design matter to my project team</h2>
<p>One of the first things I did was set up a short weekly meeting with all my teammates called a "Design Check-in." This was my chance to get the whole team on board with the design itself, its goals, and the key metrics we would use to measure success.</p>
<h3>Lessons</h3>
<p>As a developer working closely with designers, I learned to trust the design decisions made and the rationale behind them, while also knowing when assumptions need to be checked. The people around me are a resource to keep myself honest. I tried to foster an environment where everyone felt comfortable sharing their opinion on a design.</p>
<h3>Outcomes</h3>
<ul>
<li>The team became another resource to verify assumptions and inform decisions</li>
<li>Developers started asking questions about design decisions and contributing their own suggestions</li>
</ul>


At The Co-operators, I was a full-stack mobile developer on an agile team with other developers and a UI/UX team. I grew as a developer and learned a lot about the UX process from my colleagues. We worked closely together to bring their vision to life. I also brought my own technical knowledge and motion-graphics experience.

- [Making design matter to my project team](#making-design-matter)

## Making design matter to my project team

One of the first things I did was set up a short weekly meeting with all my teammates called a "Design Check-in." This was my chance to get the whole team on board with the design itself, its goals, and the key metrics we would use to measure success.

### Lessons

As a developer working closely with designers, I learned to trust the design decisions made and the rationale behind them, while also knowing when assumptions need to be checked. The people around me are a resource to keep myself honest. I tried to foster an environment where everyone felt comfortable sharing their opinion on a design.

### Outcomes

- The team became another resource to verify assumptions and inform decisions
- Developers started asking questions about design decisions and contributing their own suggestions


The Co-operators Mobile

The Co-operators is an insurance company that provides home, auto, life, business, farm, and wealth insurance. The Co-operators Mobile App lets clients make claims and payments, view policy details, and access auto liability slips, all from their mobile device.


<p>As one of my first user-centered projects, I picked something where I could use my own experience as a significant research resource. From there, I was able to create a concept that I would go on to iterate and gather feedback on.</p>
<p>Here's what I learned while working on it:</p>
<ul>
<li>Doing user interviews, without the interview</li>
<li>Spending time on the problem makes the solution clear</li>
</ul>
<h2>Doing user interviews, without the interview</h2>
<p>Being a UX student inside my own target audience meant I could observe day-to-day pain points constantly — sitting next to other students cramming for deadlines, watching how they triaged what to work on next, and noting which tools they fell back to (paper notebooks, Google Calendar, Notes apps). That ambient research informed early concepts long before I sat anyone down for a formal session.</p>
<h2>Spending time on the problem makes the solution clear</h2>
<p>The temptation with a personal project is to jump straight into the solution — "I'll build a kanban board with grade tracking." Instead, restating the problem repeatedly forced me to separate the <em>what</em> (prioritize work) from the <em>how</em> (a list? a grid? a Pomodoro timer?). Once the problem was crisp, the solution shape mostly chose itself.</p>


As one of my first user-centered projects, I picked something where I could use my own experience as a significant research resource. From there, I was able to create a concept that I would go on to iterate and gather feedback on.

Here's what I learned while working on it:

- Doing user interviews, without the interview
- Spending time on the problem makes the solution clear

## Doing user interviews, without the interview

Being a UX student inside my own target audience meant I could observe day-to-day pain points constantly — sitting next to other students cramming for deadlines, watching how they triaged what to work on next, and noting which tools they fell back to (paper notebooks, Google Calendar, Notes apps). That ambient research informed early concepts long before I sat anyone down for a formal session.

## Spending time on the problem makes the solution clear

The temptation with a personal project is to jump straight into the solution — "I'll build a kanban board with grade tracking." Instead, restating the problem repeatedly forced me to separate the *what* (prioritize work) from the *how* (a list? a grid? a Pomodoro timer?). Once the problem was crisp, the solution shape mostly chose itself.


flowr

Spend less time on time management. Flowr is an organizational tool designed by a frustrated UX student for students. Its three core functions: enabling students to prioritize work, giving them a way to track progress on that work, and quickly summarizing their grades across their classes.


<p>See some examples of visual design work I've done for companies, clients, clubs, and projects. This includes logo designs, promo material, and decks. If you'd like to learn more about a specific piece, work with me on a project, or learn about my process, please reach out. I'd be happy to chat.</p>
<ul>
<li><a href="#logo-design">Logo design</a></li>
<li><a href="#promotion-design">Promotion design</a></li>
<li><a href="#apparel-design">Apparel design</a></li>
</ul>
<h2>Logo design</h2>
<p>A set of logos and marks for clubs and projects. The set includes typeline, Ichigo, the Candywebkin Invitational, Wavelengths, DJ Labrie, Shakespearience, Science Olympics, Just Parched, Lucid Nexus, Aces Abroad, and Golden Hacks. Some marks are playful. Some are clean. Each one explores how a single graphic can carry the energy of its project.</p>
<h2>Promotion design</h2>
<p>Posters, social-media artwork, and short looping videos used to promote events. The set includes CWI promo artwork, programming campaigns, PHI Discord, Golden Speakers, and ACE ping-pong tournaments.</p>
<h2>Apparel design</h2>
<p>T-shirts and merch motifs for Balance, Panther, Panther Press, and Improv. These designs are meant to be worn often and hold up in the wash.</p>


See some examples of visual design work I've done for companies, clients, clubs, and projects. This includes logo designs, promo material, and decks. If you'd like to learn more about a specific piece, work with me on a project, or learn about my process, please reach out. I'd be happy to chat.

- [Logo design](#logo-design)
- [Promotion design](#promotion-design)
- [Apparel design](#apparel-design)

## Logo design

A set of logos and marks for clubs and projects. The set includes typeline, Ichigo, the Candywebkin Invitational, Wavelengths, DJ Labrie, Shakespearience, Science Olympics, Just Parched, Lucid Nexus, Aces Abroad, and Golden Hacks. Some marks are playful. Some are clean. Each one explores how a single graphic can carry the energy of its project.

## Promotion design

Posters, social-media artwork, and short looping videos used to promote events. The set includes CWI promo artwork, programming campaigns, PHI Discord, Golden Speakers, and ACE ping-pong tournaments.

## Apparel design

T-shirts and merch motifs for Balance, Panther, Panther Press, and Improv. These designs are meant to be worn often and hold up in the wash.


Writing