- CASim: Internal AI Assistant
-Designed and architected an internal AI assistant, built on a custom MCP server, that makes years of inconsistent construction data answerable. Currently in UAT and beta testing.
-Camp 1 · Selected work
+Three projects, from AI to enterprise scale
+
+ AI and agent design
+CASim: making years of inconsistent construction data answerable
+Designed an AI assistant that answers project questions from years of messy construction records.
+- Role: creative lead and architect
- Outcome: users ask, the system finds
Weekly AI-Powered Work Summary
-After archiving my work entries for the week, I found myself running a second, separate tool to generate a weekly summary. Now, I start the day, capture tasks, review, and archive, then summarize using AI.
-ArchParser
-Architectural drawing analysis platform for OCR-based architectural drawing analysis management.
-Task Management System
-Lead designer for Task-it, Amazon's internal task management platform. Consolidated 3-4 disparate tracking tools into one unified system, reaching 500 daily active users across AWS within 18 months of launch.
-Component Library
-Built comprehensive design system for construction management software spanning web and iOS applications. Created design tokens, component documentation, and prototypes that accelerated development cycles by 25%.
-Application Lifecycle Management
-Designed enterprise project management for OpenShift teams at Red Hat. Created seamless IDE integration and workflow tools for developers managing complex Kubernetes deployments.
-
+ Enterprise scale
+Task-it: one system instead of three, at 500 daily users
+Unified three internal systems into a single workflow.
+- Role: lead designer, AWS
- Outcome: 500 daily active users
+ OCR and document AI
+ArchParser: one source of truth for plan data, built and ready to deploy
+Turned scanned plans into searchable, manageable data, designed and built end to end.
+- Role: product designer and full-stack developer
- Status: ready to test and deploy
What Colleagues Say
---[Adam] is self-driven and keeps stakeholders (Project manager, Development manager, Engineers) aligned on UX solutions...design proposals are spot-on and considerate of [our] diverse set of users.
- - Product Owner - -
--Adam is highly engaged across 6+ major features at any given time and is somehow never the blocker. Designers like this don't come around often.
- - Senior Developer Engineer, AWS - -
-+...What stood out to me while working with Adam was his positivity and confidence through every obstacle, pivot, and deadline. He is a true team player.
- - Front-End Engineer - -
More work
+-
+
- Design systemsComponent library for construction software +
- EnterpriseApplication lifecycle management at Red Hat +
- AIWeekly AI-powered work summary +
- Coming latertrailpeakdesign +
Open Source Contributions
-Beyond my professional work, I actively contribute to the open source community. My contributions span developer tools, design systems, and infrastructure projects that support the broader tech ecosystem.
-- ๐ - Tools and Utilities -
-- Developed and maintained several open source developer tools that enhance productivity and streamline workflows for both designers and software engineers. -
-- ๐ง - PatternFly -
-- Core contributor to Red Hat's professional design system (2016-2021). Designed accessible, enterprise-grade components for the open-source system now used across OpenShift, Ansible, and 50+ enterprise products (20,000+ GitHub stars). -
-- ๐ฎ - Apps and Games -
-- Created several open source applications and games that showcase innovative use of web technologies, focusing on user engagement and interactive experiences. -
-- ๐ - Documentation -
-Regular contributor to open source documentation, helping make complex technical concepts more accessible to developers.
-Camp 2 · How I work
+Gate the connectors and data scope, not the creativity.
+-
+
Show the work
People trust an answer when they can see how it was produced.
+ Make correcting cheap
A wrong answer is survivable when fixing it takes seconds and the fix sticks.
+ Ask, don't hunt
Users should state what they need, not learn where the data lives.
+
Camp 3 · Proof
+Outcomes
+-
+
- + + 500 + Daily active users + Three or four tracking tools became one platform, reaching 500 daily users within 18 months of launch. + AWS · Task-it → + +
- + + 25% + Faster development + Design tokens and documented components cut development cycles across web and iOS. + Component library → + + +
- + + UAT + Now in beta testing + Users stopped learning where data lives and started asking questions. The assistant finds the answers. + CASim → + + +
Camp 4 · About and Brimfield Labs
+I started by fixing technology, then wanted to build it.
+I began on a help desk, moved into software engineering, and found UX design at a startup. That path is why I still ship working prototypes alongside the designs, now in Claude Code every day. I was a core contributor to PatternFly at Red Hat and designed Task-it at AWS. Outside of work I build local-first apps as Brimfield Labs, because I like software that keeps your data yours.
+ +Summit · Contact
+Building AI people can trust? Let’s talk.
++ {%- if meta.email != "" %} + Email me + {%- endif %} + Download resume + Back to trailhead ↑ +
+Project Overview
-- Company:Red Hat, Inc. -
-- Role:Senior Interaction Designer -
-- Timeline:2017-2019 -
-- Team: - 2 Product Managers, 3 Engineers, 2 Designers, PatternFly Design System team -
-- THE CHALLENGE: - OpenShift developers were managing work items across 3+ disconnected tools (GitHub issues, Jira, internal tracking systems). This forced constant context-switching between their IDE, browser tabs, and project management tools, slowing development cycles, breaking focus, and creating visibility gaps for project managers. -
- The fragmentation was especially painful because developers had to: -
-
-
- Leave their IDE to check work item status -
- Manually link code commits to work items across multiple systems -
- Update work items in multiple places to keep teams synchronized -
- Context-switch an average of 20+ times per day just for task management -
- MY ROLE: - A lead designer responsible for creating a unified application lifecycle management tool that would integrate directly into the IDE, eliminating context-switching and improving developer productivity. -
-- THE SOLUTION: - I was part of a team that designed Application Lifecycle Management (ALM), a unified work item tracking system that integrated directly into the OpenShift.io IDE. The design focused on eliminating context-switching by bringing work item management into the developer's natural workflow, allowing them to create, update, and track work items without leaving their code editor. -
Key innovations included: -
-
-
- Seamless IDE integration with inline work item creation and updates -
- Automatic linking between code commits and work items -
- Real-time synchronization across team members -
- Flexible categorization supporting multiple team workflows -
- THE IMPACT:
-
-
-
-
- Integrated work item management directly into OpenShift developer workflow/li> -
- Eliminated context-switching between IDE, browser, and project management tools -
- Created seamless connection between code commits and work items -
- Reduced average work item management time by 40% through IDE integration -
- Established design patterns adopted across other Red Hat developer tools -
The Process
-- Before starting on the Application Lifecycle Management project, it was determined that the following areas would be need to be covered: -
Step 1 · Context
+OpenShift developers managed work across 3 or more disconnected tools, and every switch broke their focus.
+Work items lived in GitHub issues, Jira, and internal tracking systems. Developers moved between their IDE, browser tabs, and project management tools, which slowed development and left project managers with visibility gaps.
+-
+
- Leave the IDE to check work item status +
- Manually link code commits to work items across several systems +
- Update work items in multiple places to keep teams in sync +
- Context-switch an average of 20 or more times a day for task management +
OpportunityHow might developers create, update, and track work without leaving their code editor?
Target Users
-- Through discussions with Stakeholders and Project Management, it was decided that the target users would be set in tiers: -
-
-
-
- General Users
-
-
- those who need to add and interact with issues, update project assets, and interact daily, a mix of designers and developers -
- -
- Project Managers
-
-
-
- organizers of work, set deadlines and release dates - -
- -
- Administrators
-
-
-
- control any integrations, add-ons, and access -
-
Application Lifecycle Management flow
-
- Step 2 · Research
+Three tiers of users, and four things to settle before any visual design.
+With stakeholders and project management, we set the target users in tiers. Before starting, we agreed to cover a list of target users, a user flow, wireframes, and prototypes for user testing and feasibility.
+General users
Add and interact with issues, update project assets, and work in the tool daily. A mix of designers and developers.
Project managers
Organize work and set deadlines and release dates.
Administrators
Control integrations, add-ons, and access.

Wireframes and Workflows
-- For each section of the ALM application, workflows and wireframes were used to identify possible user paths, as well as to strategize initial designs before moving on to high fidelity mockups and prototypes. -
-From Work Items to Development
-Goals:
--
-
- Communicates to the user that direct access to developing the Work Item is available in a single click. -
- Implementation is unobtrusive and implies navigation. -
- Location will not accidentally be clicked, allowing for enough real estate for line lengths and other meta data. The location of the integration should also imply moving forward. -
- Ordered by recommendation, require users to fill in one area before moving on. -
- As a button, it needs to have a prominent place yet not take the place of a primary button (in style). -
Steps to complete the process
-
-
-
- Step 3 · Key decisions
+Moving from a work item to code had to take one click, feel unobtrusive, and never replace the primary button.
+For each section of ALM, workflows and wireframes mapped the possible paths before high fidelity mockups. For the path from work items to development, the goals were:
+-
+
- Tell users that direct access to developing the work item is one click away +
- Keep the implementation unobtrusive and imply navigation +
- Place it where it will not be clicked by accident, with room for line lengths and metadata, and imply moving forward +
- Order by recommendation and require users to fill in one area before moving on +
- As a button, give it a prominent place without taking over from a primary button +



I annotated the wireframe with call-outs so anyone could follow my thinking without talking to me. That worked especially well with colleagues in other time zones.
+
The flows and wireframes raised open questions:
+-
+
- How do we keep linking between work items accurate? +
- If a work item has a file name and line number, is the commit SHA also used to identify the connection? +
- Can a user type the URL into a browser and reach the work item, or is it generated each time? +
Wireframes
-This wireframe was created with call outs in order to communicate my thoughts around the design to anyone who saw it, but could not talk with me. Specifically, this worked extremely well when working with colleagues in other time zones where our working ours did not match up.
-
- From these workflows and wireframes, it was determined that additional questions needed to be answered: -
-
-
- How do we handle accuracy between the linking of work items? -
- If the work items has a fine name and line number, is the commit SHA also used to help identify the connection? -
- Are we able to type the URL in a browser and navigate to the work item? (Does it have a unique link or is it randomly generated each time?) -
Visual Design
-After completing the wireframes and flows, a sample visual design was created. This design was created using the in-house design component library.
-
- Step 4 · Final design
+A unified tracker inside the IDE, built with the in-house component library.
+I created a visual design with the in-house component library after the flows and wireframes were complete. The key ideas were:
+-
+
- Seamless IDE integration with inline work item creation and updates +
- Automatic linking between code commits and work items +
- Real-time synchronization across team members +
- Flexible categorization supporting multiple team workflows +

Results & Impact
-Adoption & Launch
--
-
-
- Launched as core feature of OpenShift.io in 2018 -
- Adopted by multiple development teams within first 6 months -
- Integrated with GitHub, reducing average work item management time -
- Expanded to support multiple project management methodologies (Agile, Kanban, custom workflows) -
User Feedback
--
-
-
- Developers consistently praised the IDE integration for eliminating context-switching -
- Post-launch surveys showed positive feedback -
- Reduced reported frustration with task management from "major pain point" to "barely noticeable" -
Business Impact
--
-
-
- Improved cross-team visibility into development progress and project status -
- Reduced time spent on administrative task management, allowing developers to focus on coding -
- Design patterns and PatternFly components I created were adopted across other Red Hat developer tools -
- Demonstrated value of deeply understanding developer workflows before designing tools for them -
Step 5 · Impact
+Launched in 2018, adopted by several teams in six months, and reused across other Red Hat developer tools.
+Adoption and launch
Launched as a core feature of OpenShift.io in 2018, integrated with GitHub, and extended to support Agile, Kanban, and custom workflows.
User feedback
Developers praised the IDE integration for removing context-switching. Reported frustration moved from “major pain point” to “barely noticeable”.
Business impact
Better visibility into progress and status, less time on administrative task management, and patterns and PatternFly components adopted across other Red Hat developer tools.
What I Learned
-- This project taught me invaluable lessons about designing for developers: -
-
-
- Understand the workflow before designing the tool. By spending weeks observing OpenShift developers and understanding their daily routines, I identified friction points that weren't immediately obvious, like the cognitive cost of switching between tools and the importance of maintaining flow state. -
- The best developer tools are invisible. Developers want tools that integrate seamlessly into existing workflows rather than requiring them to adapt to new processes. ALM succeeded because it met developers where they already were, in their IDE, rather than forcing them to go elsewhere. -
- Developer experience is user experience. Too often, internal developer tools are treated as purely functional without considering the human experience. By applying rigorous UX research and design thinking to ALM, we created a tool that developers actually enjoyed using. -
- Working on ALM helped me identify gaps in PatternFly for developer tool use cases, leading to new components and patterns that benefited the entire Red Hat ecosystem. -
- The success of ALM reinforced that internal tools and developer experiences deserve the same level of design craft and user research as consumer products, and that investing in that craft pays dividends in productivity, satisfaction, and adoption. -
-Step 6 · What I learned
+Understand the workflow first, make the tool invisible, and treat developer experience as user experience.
+Understand the workflow before designing the tool
Weeks observing OpenShift developers surfaced friction I would not have guessed, like the cost of switching tools and protecting flow state.
The best developer tools are invisible
ALM worked because it met developers in their IDE instead of asking them to go elsewhere.
Developer experience is user experience
Rigorous research and design made a tool developers enjoyed using.
PatternFly had gaps
Working on ALM exposed gaps for developer tool use cases and led to new components and patterns for the whole ecosystem.
Project Overview
-- Role:Product Designer & Full-Stack Developer -
-- Type:Personal Project (originally intended as a CAS tool) -
-- Stack:TypeScript monorepo, NestJS, React, RadixUI, MySQL, Tesseract.js, built with Claude Code -
-- Status:Demo-ready, paused while higher-priority CAS projects took precedence -
-Construction project managers at Component Assembly Systems needed to pull metadata from hundreds of architectural drawing PDFs. Entering drawing numbers, revision dates, and project names from title blocks by hand was slow, error-prone, and impossible to sustain on 500+ page sets, and no existing tool handled custom title block layouts across different architectural firms. I interviewed project planners and managers about their workflows, then designed and built ArchParser to automate the extraction.
-ArchParser is a TypeScript monorepo with a NestJS backend for OCR processing and a React frontend for managing drawings. Demonstrations have processed over 200 drawings, and users of the current manual process estimated it would save roughly half a day (4 to 5 hours) of manual work per drawing set. That figure is an estimate, not a measured result.
--
-
- Processes 500+ page PDF drawing sets with memory-optimized batch processing -
- A visual template creator lets non-technical users configure extraction, so projects don't wait on a developer -
- Each extraction shows a confidence score out of 100, so users can proceed with high-confidence results and review the rest -
- Revision tracking and real-time progress updates support long-running jobs on large drawing sets -
Key Design Decisions
-The technical work is summarized further down, but the choices that shaped how people actually use ArchParser were design decisions. Four mattered most.
-1. Let users build templates, not developers
-Every OCR template tells the system where to look for a drawing number, title, date, and revision. The alternative was to have developers configure each template. I rejected it for two reasons. Title block layouts vary with file types, architectural firms, and project size, so the number of templates was never going to be small or stable. Projects also move fast, and waiting on a developer for every new layout would have slowed the very projects the tool was meant to help. The visual template creator lets a project manager draw the regions on a sample page and export the template themselves.
-2. Design for confidence and review, not blind trust
-OCR is never perfect on architectural drawings, so I designed the error handling around confidence and the ability to review. Each extraction shows a confidence score out of 100. In practice, when confidence was around 75, users generally proceeded with what the system provided, and they still reviewed a random sample of files to check it. Anything wrong could be corrected inline. The goal was to make a wrong result easy to spot and cheap to fix, and to let users decide how much to trust the output.
- -3. Consistency over novelty, even with an AI partner
-Claude Code suggested changes to button placement and some layouts. I rejected them because they differed from what was already present in the system, and changing familiar patterns would have hurt usability for people who already knew the interface. Claude Code sped up implementation, but judgment about the user's existing context stayed with me.
-4. AI search as an optional add-on
-I designed the semantic search to be optional, for the point when the company adopts an AI platform. It supports Claude, OpenAI, or a local Ollama model, so a team can choose based on budget and privacy needs. The core product works fully without it.
-The Template Creator
-The template creator is a standalone HTML and JavaScript tool built with PDF.js that works offline with no backend dependency. Users upload a sample PDF, draw rectangles over the title block, label each region (drawing number, title, date, revision), and export a template file for ArchParser.
-
-
- Visual Progressions
-- The visual design progressed quickly, but one idea held from the beginning: get users into their jobs as quickly and easily as possible. -
-Step 1 · Context
+Entering drawing numbers and revision dates by hand was slow and error-prone on 500+ page sets, and no tool handled custom title blocks.
+Opportunity+How might project managers get drawing metadata without typing it, however each firm lays out its title block?
What I did alone
+ArchParser had one person on it, so every layer of the product went through me, from the first interview to the last test.
+I interviewed project planners and managers about how they pulled metadata from drawing sets, then turned what I heard into requirements, including support for title block layouts that vary by architectural firm.
I designed the template creator, the confidence and review model, the dashboard, and the drawing review screens, and kept them consistent with patterns users already knew.
I built the React and Vite frontend with RadixUI, the NestJS backend, and the OCR pipeline, with Claude Code as a development partner. The backend has 14 test suites with 53 tests, and the frontend and backend share TypeScript types.
Working with Claude Code
-I used Claude Code as a development partner across architecture, implementation, and debugging. We weighed trade-offs such as absolute versus relative paths and synchronous versus batch processing before writing code, and it was most useful on TypeORM migrations, NestJS module structure, and tracking down memory and path-resolution bugs. It also helped draft the CLAUDE.md and README files that explain why decisions were made. Design judgment stayed with me, as in decision 3 above.
+Step 2 · Research
+I interviewed planners and managers before designing anything. Two findings shaped the product.
+Layouts never stand still
Title blocks vary by firm, file type, and project size, and projects can’t wait on a developer for each one.
Trust is a dial
At confidence around 75 out of 100, users generally proceeded, and still reviewed a random sample.
+Users of the manual process estimated about 4 to 5 hours saved per drawing set.
I interviewed 2 project managers and 3 planners about how they pull drawing metadata today.
Technical Architecture
-ArchParser is a monorepo with three workspaces: a NestJS backend, a React and Vite frontend built with RadixUI, and shared TypeScript types that catch API contract drift at compile time. The backend handles PDF-to-PNG conversion and Tesseract.js extraction, configurable OCR templates, a WebSocket gateway for live progress, and the optional LLM service. TypeORM and MySQL store jobs, drawing sets, drawings, templates, and knowledge chunks, with self-referencing drawing sets for revision tracking. The frontend includes a filterable dashboard, a PDF upload workflow, drawing review pages with inline editing, and a mock server so the interface can be developed without the backend. The backend has 14 test suites with 53 tests.
-Step 3 · Key decisions
+Four decisions shaped how people use ArchParser, and one idea held throughout: get users into their jobs quickly.
+Users build templates, not developers
A visual creator replaced developer-configured templates, so projects never wait on a developer. Because I was designing and building it, I could ship it as a standalone offline tool instead of writing a spec for someone else to interpret.

Confidence, not blind trust
Each extraction shows a score out of 100 and can be fixed inline. Since I owned the whole stack, I could carry that decision from the OCR output through to the inline correction in the review screens.

Consistency over novelty
I declined AI-suggested layouts that broke patterns users already knew.

AI search is optional
It supports Claude, OpenAI, or a local model, and the core product works fully without it.



Real-world tests forced two fixes
+500+ page PDFs ran out of memory, so I moved to adaptive batches. Records lost their links after restarts, so I centralized paths and migrated 373 records.
+Claude Code’s suggested button placements and layouts might improve the interface.
They differed from patterns already in the system, and changing familiar patterns would hurt people who knew it.
I kept the existing patterns. Claude Code sped up implementation, and with no second designer to review the call, judgment stayed with me.
Key Iterations
-Real-world testing forced two architectural changes. First, 500+ page PDFs exhausted memory because the first version converted the whole document to images at once. I switched to single-page conversion with batch sizes that adapt to document size, plus sequential OCR processing and memory monitoring, and large sets now process without crashes.
-Second, processed drawings lost their link to database records after restarts, caused by inconsistent path resolution, a naming mismatch on deletion, and absolute paths stored in the database. I centralized path handling, standardized folder names, stored relative paths, and migrated 373 existing records, which also made the system portable across environments. The dashboard was refined too, with independent pagination and sorting, date and status filters, and a Kanban-style monitor view, after high-volume tables proved hard to navigate.
+Step 4 · Final design
+Users draw regions on a sample PDF, label them, and export a template. The tool works offline.
+



What I Learned
--
-
- Test with realistic data from the start. The first version worked on small PDFs and failed on real 500+ page sets. Building with realistic data earlier would have surfaced the memory problem sooner. -
- Empowering users beat clever engineering. The visual template creator did more for adoption than any backend optimization, because it removed a bottleneck. -
- An AI partner speeds implementation, not judgment. Claude Code accelerated architecture work, debugging, and boilerplate, but the decisions about consistency and what users already know were mine to make. -
Step 5 · Impact
+Demo-ready, and built to cut half a day from each drawing set.
+-
+
- 200+Drawings processed in demonstrations. +
- 4 to 5 hrsEstimated savings per drawing set. This is an estimate from users, not a measured result. +
- ReadyTo test and deploy on a single source of information. +
Project Links
--
-
-
-
-
- Demo Site (no data) - -
- -
-
-
- Visual Template Creator Tool - -
-
Step 6 · What I learned
+Test with real data, empower users, and keep judgment human.
+Test with realistic data from the start
Small PDFs worked. Real 500+ page sets failed.
Empowering users beat clever engineering
The template creator did more for adoption than any optimization.
An AI partner speeds implementation, not judgment
Decisions about what users already know stayed with me.
Owning every layer shortens the loop and removes the reviewer
When real-world testing exposed the memory and path problems, I could change the design, frontend, and backend in one pass instead of handing a ticket across a team. The tradeoff was that nobody else was checking my work, which is why I leaned on tests and shared types.
Project Overview
-Role:Creative Lead & Architect (design, MCP server, agents, prompts, and tooling)
-Type:Internal Tool
-Stack:TypeScript MCP server, Claude Desktop, MCP Inspector, custom web interface
-Status:In Progress ยท Currently in UAT and beta testing
-Step 1 · Context
+One question was close to impossible to answer: how did a project’s budget compare to its final financials?
+Every work order, change order, and supply markup existed in our system. Nothing connected them, so answering took manual assembly across screens, and most people didn’t try.
+Opportunity+How might anyone get a trustworthy answer about a project’s financials without knowing where the data lives?
What I did alone
+I was the only designer, researcher, and front-end developer on CASim, and I also architected the MCP server, agents, prompts, and skills behind it. One person carried the work from the first question to the interface people use every day.
+I interviewed stakeholders about the question that was nearly impossible to answer, audited years of data to find where names, dimensions, and identifiers had drifted, and tested tool behavior in MCP Inspector and Claude Desktop before judging how it felt in the interface.
I designed how the assistant reasons about project data and the access model that decides what it can reach.
I built the MCP server and the front end of the custom interface. The development team’s part was updating the source data, after the naming decisions were made.
- One question was close to impossible to answer at our company: how did a project's budget compare to its final financials once every work order, change order, and supply markup was counted? All of that information existed in our system. Nothing connected it, so answering took manual assembly across screens, and most people didn't try. -
- - -- I assumed the hard part would be the AI. It was the data. Over the years, data entry had drifted from consistent inputs to a loose, sometimes conflicting set of values. Construction supplies were the clearest example: names slipped, dimensions were written several ways, and multiple identifiers meant the same product with no link between them. An assistant that sits on top of that data inherits every inconsistency, and it answers confidently regardless. -
-Step 2 · Research
+I assumed the hard part would be the AI. It was the data, drifted over 20+ years.
+Names slipped
The same supply appeared under different names.
Dimensions varied
Sizes were written several ways.
No shared identifier
Several identifiers meant one product, with no link.
+An assistant on top of inconsistent data inherits every inconsistency, and it answers confidently regardless.
I worked with 6 project managers to learn how they rebuilt financials by hand, and audited years of data to find where names, dimensions, and identifiers had drifted.
The decision
-We had two realistic paths. The first was to build a terminology file, a definitions layer that mapped every variant name and dimension to a canonical meaning so the assistant could translate on the fly. The second was to work with the executive team to decide what the defaults should be, then have the development team update the data and database to match. -
-- The terminology file was the faster, lower-risk option, and it was tempting for that reason. I rejected it because it would have hardened the mess into a permanent dependency. Every new variant would need a new mapping, someone would have to own that file indefinitely, and the assistant's answers would only be as good as the last person who updated it. We chose the harder path of returning to a single consistent naming convention and fixing the source. -
-Step 3 · Key decisions
+I rejected the faster fix, a terminology file, because it would harden the mess into a permanent dependency.
+Fix the source, not the symptom
+A definitions layer would translate every variant on the fly, but someone owns it forever. Executives set the defaults and developers updated the data instead.
+Gate the connectors, not the creativity
+A working server let IT leadership see exactly what the assistant could and couldn’t reach.
+The cleanup drew fair pushback about what might be lost. Early results answered it. I also backtracked more than once to cover gaps the first architecture missed. The research behind that call was mine, so explaining it and answering for what the cleanup might miss was my job too.
+A terminology file mapping every variant to one meaning was the faster, lower-risk path.
Every new variant would need a new mapping, and answers would only be as good as the last update.
Executives set the defaults and developers corrected the data at the source.
What I built
-I was the creative lead and architect for CASim, and I built the core pieces myself. That includes the MCP server, the agents, prompts, and skills that shape how the assistant reasons about project data, and the tooling that connects it all. The server runs against three clients: Claude Desktop for daily use, MCP Inspector for testing tool behavior directly, and a custom interface for the people who will use CASim day to day. Keeping those three in play meant I could check whether a tool behaved correctly in isolation before judging how it felt in the interface. -
- -- I also designed the access model around a simple principle I later presented to IT leadership: gate the connectors and data scope, not the creativity. A working server made the argument concrete, because leadership could see exactly what the assistant could reach and what it couldn't. -
-Step 4 · Final design
+One server, three clients: Claude Desktop for daily use, MCP Inspector for testing, and a custom interface for everyone else.
+With design, research, and the front end all in my hands, a bad answer could be traced to the tool, the prompt, or the data without waiting on a handoff.
+
Outcome
-- The decision was not universally popular. There was real pushback about how the data was being handled and about what information might be missed, forgotten, or lost in the cleanup. That concern was fair, and it shaped how carefully we approached it. -
-- The initial results answered it. They showed there was real insight sitting in the system that nobody could reach, and that the cleanup path was the right one. The question that had been nearly impossible, budget against end-of-project financials including work orders, change orders, and supply markup, became answerable. CASim is now in UAT and beta testing, so the adoption story is still being written. -
-Step 5 · Impact
+The question that was nearly impossible became answerable.
+-
+
- AnswerableBudget against final financials, including work orders, change orders, and supply markup. +
- UATNow in beta testing, so the adoption story is still being written. +
Reflections
-- Now that the project is in beta and proceeding through UAT, I am able to reflect on what I'd do differently and, potentially, what I would change moving forward in how I approach AI products. -
-- Looking back on the beginnings of the project, I would have researched and tested more before diving into creation. There were many times where I had to stop, research, and backtrack in order to cover either a gap that I had in the system, or a concern that wasn't addressed in the original architecture. While this did not delay the project, it did cause unnecessary churn that could have been avoided by taking a little extra time with research. -
-- Additionally, the pushback on data inconsistencies was unexpected although it should not have been. With a system that is 20+ years old, there are bound to be drifts in how data is stored and what has been entered by the thousands of users of the years. -
-Step 6 · What I learned
+Research first, expect pushback, and fix the source.
+Research before building
Extra time up front would have avoided the backtracking.
Expect the data to push back
In a 20+ year system, drift is certain.
Fix the source, not the symptom
The harder path made the answers trustworthy.
Working alone sharpened the cost
Nobody else was positioned to catch the gaps in my research, so the checks had to live in how I worked. That is why testing each tool in isolation in MCP Inspector mattered so much.
CASim is in UAT and beta testing. I will update this page as adoption results come in.
-
-
-
- Step 1 · Context
+One of the most up-voted feature requests had a built-in problem: color alone cannot carry meaning.
+A color picker is not accessible by nature. The goal of this component was to let users choose colors for labels, and to offer alternatives such as patterns and icons.
+Opportunity+How might label colors stay distinguishable for everyone, whatever they can see?
Step 2 · Key decisions
+I verified every color against light and dark backgrounds and started with the most ubiquitous component, labels.
+I chose a base set of colors from the design system palette. Each was checked against a light background (#ffffff), a dark background (#010101), and multiple layers.
++In total, 44 combinations met WCAG AA, with 18 meeting WCAG AAA.

With the PM and development team, we agreed labels were the best place to start, since they are the most common across the system.
+
Step 3 · Final design
+A prototype environment let us test the new labels in real time without exposing unfinished work to production users.
+To compare the current label scheme with the new component, I worked with the development team on a prototype environment. I tested the interactions and visuals there, and tested the component with users.
+
Step 4 · Impact
+The color picker launched to production, and the findings fed another round of design and testing.
+Measured results are not available for this page yet. What I can say is that the component shipped, and the findings from this round became follow-up work.
+Project Overview
-- Built comprehensive design system for Component Assembly Systems' construction management platform, spanning web and iOS applications. -
-Created unified visual language, reusable components, and documentation that accelerated development cycles.
-- Role:Lead Product Designer -
-- Timeline:2024-Present -
-- Platform:Web & iOS -
- +Step 1 · Context
+Construction management software across web and iOS needed one visual language and one set of reusable parts.
+I built the design system for Component Assembly Systems’ construction management platform. It spans web and iOS, with a unified visual language, reusable components, and documentation that speeds up development.
Design Tokens
-
-
-
-
- --cas-spacer-xxs: 0.25rem; /* 4px */
- --cas-spacer-xs: 0.5rem; /* 8px */
- --cas-spacer-sm: 0.75rem; /* 12px */
- --cas-spacer: 1rem; /* 16px */
- --cas-spacer-md: 1rem; /* 16px */
- --cas-spacer-lg: 1.25rem; /* 20px */
- --cas-spacer-xl: 1.5rem; /* 24px */
- --cas-spacer-xxl: 2rem; /* 32px */
- --cas-spacer-xxxl: 3rem; /* 48px */
-
-
- Step 2 · Design tokens
+Tokens came first, so every component inherits color, type, spacing, and icons from one source.
+


Spacing and sizing
+--cas-spacer-xxs: 0.25rem; /* 4px */
+--cas-spacer-xs: 0.5rem; /* 8px */
+--cas-spacer-sm: 0.75rem; /* 12px */
+--cas-spacer: 1rem; /* 16px */
+--cas-spacer-md: 1rem; /* 16px */
+--cas-spacer-lg: 1.25rem; /* 20px */
+--cas-spacer-xl: 1.5rem; /* 24px */
+--cas-spacer-xxl: 2rem; /* 32px */
+--cas-spacer-xxxl: 3rem; /* 48px */
+Components
-
-
-
-
-
- Documentation
-All design and component documentation was created using Storybook. -
-
- Step 3 · Final design
+Buttons, cards, tables, and form controls, specified so they are ready for production.
+




All design and component documentation lives in Storybook.
+
Impact
--
-
-
- Established first unified design system across web and iOS -
- Reduced design-to-development handoff time by providing production-ready component specifications -
- Created foundation for rapid feature development and consistent user experience -
- Documented design tokens and usage guidelines for engineering team -
Step 4 · Impact
+The first unified design system gave engineering a foundation for faster, more consistent features.
+-
+
- Established the first unified design system across web and iOS +
- Reduced design-to-development handoff time with production-ready component specifications +
- Created a foundation for rapid feature development and a consistent user experience +
- Documented design tokens and usage guidelines for the engineering team +
-
- New Game collects opposition, date, location, and half duration, everything you'd put on a physical scoresheet, plus roster selection from a pre-built player list with jersey number and position. -
The Game vs. Scrimmage toggle is a small but deliberate decision: scrimmages have different stakes and different lineup dynamics, and I wanted the history to reflect that distinction clearly. -
- - - ### Substitutions - - :::card - Substitutions were a meaningful product decision. Mid-game sub support, with a distinct "substituted out" state separate from bench status, reflects how substitutions actually work: a player who comes off isn't the same as a player who never started. Getting that distinction right matters for per-player stats to be accurate. - ::: - -
-
-
-
-
- Step 1 · Context
+Pen and paper is fast but leaves nothing useful, and third-party apps own your data.
+Coaching a youth soccer team generates a surprising amount of data: scores, substitutions, player minutes, goals, assists, saves, and cards. Capturing it is not the hard part. Every existing option forced a tradeoff I was not willing to make. Third-party apps are convenient, but they require accounts and are built for organizations, not individual coaches.
+Opportunity+How might a coach track a whole game with one thumb, and keep the data?


Step 2 · Key decisions
+I chose Swift and local storage because a sideline app has a performance contract: launch instantly, respond without lag, never drop data.
+A PWA or React Native wrapper would have been faster to build, and I have shipped both. Native with local storage satisfies all three requirements, with no sync, no account to authenticate, and no API that might be down at kickoff.
++Every decision went through one person: me.
The constraint clarified scope. Without a backend, multi-device sync and shared rosters are off the table, and knowing what the app is not made it easier to build what it is.
+The core design problem is attention. During a live game a coach is watching players, calling substitutions, and talking to parents, so the app gets a glance and a thumb tap.
+Pregame
Setup handles the overhead up front: opposition, date, location, half duration, and roster selection. A Game or Scrimmage toggle keeps the history honest.
Scoreboard and quick actions
The two largest tap targets are Team Goal and Opponent Goal. Correction actions are present but smaller and lighter, so they are harder to hit by accident.
Players and activity
Tapping a player logs goals, assists, saves, shots, and cards. Each action is timestamped and tied to the half, so the post-game summary reads as a timeline.
Step 3 · Final design
+A live game screen built for a glance, and substitutions that match how they really work.
+
Mid-game substitutions have a distinct “substituted out” state, separate from bench status, because a player who comes off is not the same as a player who never started. That distinction keeps per-player stats accurate.
+


Step 4 · Impact
+In use this season, with per-player stats informing lineups and substitution planning between games.
+As a coach, historical information shapes how I plan practices, set lineups, and choose strategy.
+

Real use has mostly surfaced sequencing. The move from pregame setup into the live view needs less friction, and the post-game summary is still being refined. Those are the next iterations, and an App Store release is planned once the rough edges are resolved.
+Project Overview
-- Company:Amazon Web Services -
-- Role:Senior UX Designer (Lead Designer) -
-- Timeline:2021-2023 -
-- Team: - Collaborated with 3 PMs, 8 engineers, UX researcher -
-- THE CHALLENGE: - AWS teams were using 3-4 different task tracking tools (Jira, internal systems, spreadsheets), leading to fragmented workflows, poor cross-team visibility, and significant time wasted in context-switching. Product managers struggled to get a unified view of work across teams, and individual contributors were frustrated by having to update multiple systems. -
-- MY ROLE: - I designed Task-it, a unified task management platform that consolidated these disparate tools into a single, intuitive system with role-agnostic patterns that could serve diverse AWS teams. -
-- THE SOLUTION: - I designed Task-it, a unified task management platform that consolidated these disparate tools into a single, intuitive system. The design focused on role-agnostic patterns that could serve diverse AWS teams, from product managers tracking roadmaps to engineers managing technical debt to support teams triaging customer issues. -
- THE IMPACT:
-
-
-
-
- 500 daily active users across 15+ AWS teams within 18 months of launch -
- Consolidated 3-4 separate tracking systems into one unified platform -
- Reduced context-switching and improved cross-team collaboration -
- Drove feature roadmap through continuous user research and usability testing -
- Created scalable UX patterns now being adopted in other AWS internal tools -
The Process
-Before any design work (wireframes, mockups, prototypes) could begin, extensive user research and testing was needed.
-Research methods with example questions: -
-
-
- User interviews
-
-
-
- Ask users what their role is on their product team. -
- What product(s) do they use to manage their work? -
- If they do not use the existing internal product, why not? -
- - Competitive analysis
-
-
-
- What products are used internally, besides the previous internal-built system? -
- Why are they used? What do they provide that the current internal system does not? -
- - On-hand testing
-
-
-
- As a user, I needed to work within the system we were working to replace so that I can find the issues that currently exist. -
- Findings were compared against user interviews. Those interviews were also used as a basis for various testing methods. -
- - Observe users
-
-
-
- Watch how users use the products: where do they always visit? What tasks are they always performing? -
-
Once a baseline had been established, the first round of user flow diagrams and analysis took place. Each step in the various user flows had two goals: -
-
-
- Follow user expectations
-
-
-
- Users expected to be able to perform basic tasks, such as creating work items, viewing work items, and organizing their work in a single system. -
- - Simplify existing processes
-
-
-
- Users would not accept a more complicated process. Interviews taught me that anything more complicated than what they had would be a deal-breaker for switching to, no matter the directives from management. -
-
Target Audience
-For the initial release (scoped internally as a "beta"), the target audience consisted of Individual Contributors (IC), with a mix of high-interaction and low-interaction users. These were categorized as 1. Contributors, 2. Owners, and 3. Viewers.
--
-
- Contributor
-
-
-
- Those who actively added items to a team's task queue. -
- - Owner
-
-
-
- Individuals who were, at a high-level, responsible for the delivery and success daily and long-term tasks and goals. While not ICs, Owners had a direct hand in what tasks teams took on. -
- - Viewer
-
-
-
- Those who stayed on the "outside" of the day-to-day operations, but could influence the work taking place. Viewers were not considered to be a top-level user, but the entire process had to take into account their work. If things became harder for them to see/find, then they were likely to become a blocker to adoption. -
-
After discussions with Project Management (PM), it was determined that the target audience would be broken down into tiers: Tier 1 and Tier 2. -
--
-
- - Tier 1 consisted of those who used the existing solutions multiple times per day and could assist with driving adoption. These were the Contributors. - -
- - Tier 2 consisted of those who interactive with existing solutions on a weekly basis, and then only to monitor the work being done by those in Tier 1. - -
Step 1 · Context
+Work lived in Jira, internal systems, and spreadsheets, and nobody could see across teams.
+AWS teams used 3 or 4 different task tracking tools. That meant fragmented workflows, poor cross-team visibility, and real time lost to context-switching. Product managers struggled to get a unified view of work across teams, and individual contributors were frustrated by updating multiple systems.
+OpportunityHow might one system serve product managers tracking roadmaps, engineers managing technical debt, and support teams triaging customer issues?
User flows, Wireframes, and Mockups
-For the initial Task Details view, user flows and wireframes were used to identify possible errors. The findings from this work would go on to determine the direction of the final mockups.
-
-
- Step 2 · Research
+Users would not accept a more complicated process, so research came before any wireframe.
+User interviews
Their role, the products they use to manage work, and why some avoided the existing internal product.
Competitive analysis
What else teams used internally, and what it offered that the internal system did not.
Hands-on testing
I worked inside the system we were replacing to find its issues, then compared them against the interviews.
Observation
Where users always go, and which tasks they perform every day.
+Anything more complicated than what they had would be a deal-breaker, no matter the directives from management.
Who it was for
+The beta targeted individual contributors, with a mix of high-interaction and low-interaction users in three groups. After discussions with product management, we split them into two tiers.
+Actively added items to a team’s task queue. Tier 1: they used existing tools many times a day and could drive adoption.
Responsible for delivery and success of daily and long-term goals. Not ICs, but they shaped which tasks teams took on.
Stayed outside day-to-day operations but influenced the work. Tier 2: weekly check-ins, and a likely blocker to adoption if things got harder to find.
Initial findings
-Based off of these user flows, I determined that the success and failures paths needed to be looked at further. Depending on the user, these paths had the potential to break experiences and decrease the usability and delight in the product.
-Wireframes
-When creating wireframes, I start by taking an existing components (whether already in the application or from the component library in use) and lay out my page. From there, I begin to add some details (using the redacted script font) and basic headings. This is then reviewed with PM, Development, and, if available, fellow UX designers.
Mockups
-After reviews have been completed on the wireframes, mockups are created. In my process, I utilize mockups to get the full look/feel of the page without interactions. Once completed, these are used for user testing as well as final review with the development team.
-
-
- Step 3 · Key decisions
+Every step in every flow had two goals: follow what users expect, and make the process simpler.
+Users expected to create work items, view them, and organize their work in one system. Anything beyond that had to earn its place. I used user flows and states to find where success and failure paths could break the experience before any mockup existed.
+

Let users set the priority
+More attributes were planned, so the Task Details page had to adapt. I ran a card-sorting survey that included existing and future attributes, with one prompt: which attributes are required for you to get your work done most efficiently? Users set the order, not the team.
+
Testing and Revisions
-As part of the iterative process, I consistently looked at user feedback and heat-mapping to determine if there were any changes needed. From the beginning, it was known that additional attributes would be made available to users and that the Task Details page would have to be able to adapt accordingly.
-As part of the testing process, I created a card-sorting survey for users, where I included all of the existing attributes, as well as some future-planned attributes, and asked users to order them by priority. Priority was determined by the user, with the only prompt being "what attribute(s) are required for you to get your work done in the most efficient manner?".
-
- Revisions
-- After analyzing the results of the card-sorting user testing, additional mockups were created to task with the updated attribute priorities. -
-
-
-
- Step 4 · Final design
+Wireframes, then mockups, then three revisions driven by what users ranked.
+I start wireframes from existing components, add redacted-script placeholder text and basic headings, and review with product management, development, and fellow designers. Mockups give the full look and feel for user testing and final development review.
+

After the card sort, I revised the page to match the updated attribute priorities.
+


Results & Impact
-Adoption & Growth
--
-
-
- Launched to pilot teams in Q2 2022, reaching general availability by Q4 2022 -
- Grew from 50 pilot users to 500 daily active users within 18 months -
- Expanded across multiple AWS teams spanning product, engineering, and support organizations -
- Achieved organic growth through word-of-mouth recommendations from satisfied users -
User Feedback
--
-
-
- Post-launch usability testing showed a high satisfaction rate with overall experience -
- Users consistently praised the unified view: "Finally, one place to see all my work" -
- Engineers appreciated the flexible categorization: "Task-it adapts to how I work, not the other way around" -
- Product managers valued cross-team visibility: "I can finally see what's blocked across all my teams" -
Business Impact
--
-
-
- Consolidated 3-4 legacy tools, reducing tool sprawl and maintenance overhead -
- Improved cross-team visibility into project status, blockers, and dependencies -
- Reduced onboarding time for new AWS employees (one tool to learn instead of multiple) -
- Established design patterns now being adopted in other AWS internal applications -
- Demonstrated value of user-centered design for internal tools -
Step 5 · Impact
+From 50 pilot users to 500 daily active users in 18 months, mostly by word of mouth.
+-
+
- 500Daily active users across 15+ AWS teams within 18 months of launch. +
- 3 to 4 โ 1Legacy tools consolidated, reducing tool sprawl and maintenance overhead. +
- AdoptedDesign patterns now used in other AWS internal applications. +
Adoption
Pilot teams in Q2 2022, general availability by Q4 2022, and growth across product, engineering, and support organizations.
User feedback
Post-launch usability testing showed high satisfaction. “Finally, one place to see all my work.” “Task-it adapts to how I work, not the other way around.”
Business impact
Better visibility into status, blockers, and dependencies, and a shorter onboarding path with one tool to learn instead of several.
What I Learned
-- This project reinforced three critical lessons about designing internal tools: -
-
-
- Internal tools deserve the same design rigor as customer-facing products. By investing in proper user research, prototyping, and testing, we created a tool that users actually wanted to use, driving organic adoption without mandates from leadership. -
- Flexibility beats rigid workflows. Rather than forcing all teams into a single process, we designed role-agnostic patterns that could adapt to different team structures and workflows. This flexibility was key to achieving broad adoption across diverse AWS organizations. -
- Continuous research is essential. By conducting regular usability tests and gathering feedback throughout development, we caught issues early and built features that users actually needed, not just what we assumed they wanted. -
- The success of Task-it demonstrated that internal tools can be delightful and that investing in UX research pays dividends in adoption, productivity, and user satisfaction. -
-Step 6 · What I learned
+Give internal tools the same rigor as customer-facing products, stay flexible, and keep researching.
+Internal tools deserve design rigor
Research, prototyping, and testing built a tool people wanted to use, with adoption driven by users and not by mandate.
Flexibility beats rigid workflows
Role-agnostic patterns that adapted to different team structures were the key to broad adoption.
Continuous research is essential
Regular usability tests caught issues early and kept us building what users needed, not what we assumed.
-
-
-
-
-
-
- - - ### AI prompt architecture - - :::card-shadow - The prompt that drives the summary is split into two parts. The system instruction establishes the persona, length constraints (3 to 5 sentences), voice (first-person, no filler phrases), and the specific tone instructions for whichever mode is selected. The user message contains the serialized week data: a lean, human-readable representation of each workday with task titles, descriptions, project names, and durations. - - Before sending, the serialization step strips timestamps, IDs, and non-work categories. What reaches the model is only what a human would include if they were writing the summary prompt by hand. This matters because model output quality is directly proportional to input clarity: sending structured noise produces structured noise back. - - The prompt architecture is designed to evolve. As I use the feature and notice patterns in what I edit or regenerate, the system instructions can be tuned to match how I actually write and what different audiences respond to. The tone categories themselves may expand: a sprint summary or executive update tone would be natural additions as the use cases grow. - ::: -:::: - - - -::::section - :::card - ### Outcome - - Every week I use the standup tone on Monday morning to orient myself before the week's work begins, with the retrospective tone on Friday to close out the week. Before this feature existed, I skipped that ritual more often than not due to the fact that the tooling made it feel like work. *Now it takes less than a minute*. The summary is available wherever Timetraked is available, and the tone control means the output is usually usable with one or two edits rather than a full rewrite. - - The Weekly Report Generator extends that routine. I use it every week, and it takes less than a minute to produce a full report that used to take me about 30 minutes to write by hand. - - From a portfolio standpoint the project demonstrates a specific combination of skills: identifying friction in a real workflow, making a considered architectural decision about where a feature belongs, designing the interactions states that make AI output feel trustworthy, and shipping something that has been in daily use since it launched. -:::: +
Step 1 · Context
+Summarizing my week took a second tool, a PDF export, and manual cleanup, so I skipped it.
+Timetraked (formerly TimeTracker Pro) is a Progressive Web App I designed, built, and use every day. It installs like a native app, stores data locally by default, and needs no account. Through the day I create tasks, assign them to projects and categories, and archive each completed day.
+I built it because every time tracker I tried was either too complex for personal use or too simple to be useful. It has grown into a small, complete product with export formats, project management, offline support, and invoicing.
+
After archiving each week, I ran a second tool to generate a summary. It only accepted PDFs exported from the time tracker, only ran on a local development server, and produced output that always needed manual cleanup.
+No real integration
The generator only accepted PDFs from the time tracker. The export was the only bridge between them.
Availability
It ran on a local Vite server, so it was only reachable from my machine in a single context.
Output needing edits
It had no idea who I was writing for, so every summary came out generic and sounded the same week to week.
Opportunity+The right tool for summarizing my work week is the tool that already knows my work week.
Step 2 · Key decisions
+I extended the app instead of building a better standalone tool, and kept the full report generator separate on purpose.
+Extend, not replace
+A standalone tool would still need an export step, a file upload, or an API connection to reach my time data. It would have to work with any input, which means losing the context that makes a summary useful: what categories mean, which projects are billable, and what a typical week looks like for me.
+Extending Timetraked meant the feature reads from the same local data store as the rest of the app, with no synchronization problem and no format negotiation. It also let the feature be opinionated. It excludes break and lunch categories, understands the project and client structure, and groups a week of task descriptions into a narrative instead of a list.
+Two tools, one deliberate boundary
+The short weekly summary and the full weekly report do different jobs. The summary lives inside Timetraked because it reads daily entries from the same database. The Weekly Report Generator is separate: you paste in the summary and the AI writes a full report from a template built into the system.
+The hardest question was whether to fold the generator in too. I kept it separate so it works with any summary, not only ones tied to one tool’s data format, and so its use cases can grow.
+The cost
Another repository, another set of dependencies, and a copy-and-paste step between the tools. I accepted all three to keep the generator reusable.
What is next
The template is built in for now. Making it easy to customize for different outputs is the next item, and the generator is private for now, with plans to make it public.
Step 3 · Final design
+The AI is a visible step in a workflow, not a magic trick: configure on the left, review and edit on the right.
+Two-panel layout
+At wider viewports, controls sit on the left and output on the right. The interaction has two modes, configuring the request and reviewing the result, and one scrolling column would blur them. The left column handles week navigation, the data breakdown, and tone selection. The right column only reacts, showing one of four states: idle, generating, error, or a draft ready to edit and copy.
+

Generation as a legible transition
+While generating, the right panel names the week being summarized and shows staggered skeleton lines. The idle state uses a dashed container with a short explanation, so the layout never reads as broken on first load. Errors are structured and recoverable: a header naming the failure, a plain-language description, and an inline “Try again”.
+
Tone as a product decision
+The tone selector reflects a real choice I make every week about who I am writing for. Each tone maps to different system prompt instructions and produces meaningfully different output. Changing the tone resets the existing summary, so you never mistake a standup draft for a client-ready one.
+


Editable output by default
+The summary appears in an editable text area, which frames the AI correctly: it drafts, the human approves. A copy button and a short “changes are not saved” note complete the model, and a regenerate button sits beside copy for the two things people want to do with a draft: try again or take it.
+Prompt architecture
+The system instruction sets the persona, length (3 to 5 sentences), voice (first-person, no filler), and the instructions for the selected tone. The user message carries the serialized week: task titles, descriptions, project names, and durations. Before sending, serialization strips timestamps, IDs, and non-work categories, so the model sees only what a person would write into a prompt by hand. Sending structured noise returns structured noise.
+The prompt is designed to evolve as I notice what I edit or regenerate, and the tone categories can expand, for example to a sprint summary or an executive update.
+Step 4 · Impact
+A ritual I used to skip now takes under a minute.
+I use the standup tone on Monday morning to orient the week and the retrospective tone on Friday to close it out. Before this feature, I skipped that ritual more often than not because the tooling made it feel like work. The summary is available wherever Timetraked is, and the output usually needs one or two edits instead of a rewrite.
+The Weekly Report Generator extends the routine. I use it every week, and it produces a full report in under a minute that used to take about 30 minutes to write by hand.
+The project shows a specific mix of skills: finding friction in a real workflow, deciding where a feature belongs architecturally, designing the interaction states that make AI output feel trustworthy, and shipping something that has been in daily use since launch.
+
-
-
-
-