These essays explore the communication problems that rear their heads when systems are technically functional yet difficult for people to understand, trust, or use. They are less about isolated writing samples and more about the way I think: from the outside in, with attention to public trust, human behavior, complexity, and whether communication actually helps people act.

One of my strengths as a communicator is understanding how different media channels shape the way people learn. My approach to instructional video is influenced by instructional design frameworks like ADDIE and Mayer’s Principles of Multimedia Learning, but the core question is the same one I bring to every communication project: what does the audience need to do, and what is getting in their way?

Video becomes especially useful when the task involves a workflow, spatial movement, software navigation, practical steps, or an audience that benefits from seeing and hearing the process instead of reading about it. A good instructional video can reduce cognitive load by showing the sequence, pacing the explanation, and providing enough context to keep the viewer moving without feeling overwhelmed.

Creating instructional videos taught me that video-based guidance is not all that different from technical writing. The format changes, but the core problem stays the same: someone is trying to do something, and the communication needs to help them get there without getting lost. Again, my curiosity comes into play here. Instead of deciding "I know how to solve the problem," I ask questions: What are they trying to accomplish? What do they already know? Where are they likely to get stuck? From there, I break the task into smaller steps, sequence the information around the way someone is likely to learn it, and build enough context that the viewer can move forward.

The real work goes beyond explanation. It is deciding what to show, what to say, what to slow down, what to repeat, and what to cut. It also means thinking about how someone will find the resource in the first place, which makes titles, descriptions, tags, playlists, and the larger structure around the content part of the communication strategy. When viewers ask follow-up questions or search patterns reveal what people are still struggling with, that becomes part of the feedback loop. To me, a good instructional video is a user guide with pacing, visuals, and discoverability layered on top.

The audience could complete the objective.

I can’t share everything I’ve produced, but one example comes from a front-end web design class I took in college. We were required to build and host a mock website, but there was a gap in the process: many students did not know how to host a site, and some thought the only option was paying for a domain. The assignment was clear. The path forward was not.

So I made a short, unscripted video walking classmates through a free GitHub hosting workflow. It would never pass as polished onboarding material or formal workflow documentation, and that is partly why I think it matters. Even rough, imperfect communication can succeed when it reaches the right audience at the right moment and helps them do the thing they need to do.

The result was simple: students had less anxiety, did not feel pressured to pay for something they did not need, and were able to follow the workflow to complete the class objective. The video earned more than a few thank-you messages from classmates, but the more important lesson was the outside-in one. In that case, I was part of the audience experiencing the friction. I bring that same mindset to every project: if the end user cannot complete their objective, especially when they are required to, the communication has not done its job yet.

I’ve also created instructional videos for navigating systems in contract roles, though I cannot share those directly here. As a public example of the same approach, I’ve included videos I made for players learning The Long Dark. These sit at the same intersection: “I want to do this” and “Great, how do I?” The subject matter is different, but the communication problem is familiar: understand the audience, break down the system, identify the friction, and make the next step easier to take.

During my time at university, I made a great many connections with colleagues from varied backgrounds, family lives, and socioeconomic statuses. During one particular class, we were tasked with drafting a mock recommendation report, as if we were in the workplace, and suggesting a change to leadership.

Two other students and I paired up to take on this capstone project for the class. Instead of just making a mock entry to satisfy the project requirements, we decided to tackle something else. Something that was personal to all three of us as students.

We decided to create an item we could also forward to university leadership.

Why?

We wanted to propose tangible, meaningful changes to how Kennesaw State approaches its nontraditional student population, a group all three of us belonged to.

During our time at university, each of us had studied issues related to diversity, vulnerable populations, and institutional access from different angles. That background shaped how we thought about systems, how they interact with one another, and how even well-intentioned structures can exclude certain groups or cause harm when their needs are not fully understood. This project became one of the early foundations for how I think about communication, equity, and systems today.

Because all three of us had also experienced the university as nontraditional students, we decided to pair that academic lens with the roadblocks, hurdles, and barriers we had encountered firsthand. From the outset, the report was no longer just a project built to satisfy a grade requirement. It became a chance to advocate for a growing segment of the university population that faced increased friction and limited institutional support.

Our goal was straightforward: use the lenses of equity, inclusion, and student support to present targeted, tangible recommendations to university leadership. We grounded those recommendations in available data, student experience, and existing models from other institutions so the final report could move beyond identifying the problem and offer realistic paths forward.

Good recommendations often start with lived experience. Stronger ones come from pairing that experience with data, targeted research, and a lens that takes support for vulnerable populations seriously.

We began by researching nontraditional student outcomes across universities, including graduation rates, financial pressures, access to support services, and the barriers that repeatedly shaped student success. We also looked at the intersections among university policy, government aid programs, childcare access, advising models, and other institutional support functions.

The goal was not simply to say, “Students like us need to be heard.” That mattered, but it was not enough. We wanted the recommendations to be actionable, evidence-based, and grounded in existing models. By pointing to programs and structures already working elsewhere, we could show that the university did not have to build solutions from scratch. The foundation existed. The question was whether KSU would adapt it to better serve its own students.

We passed the class.

More importantly, the report earned recognition beyond the assignment itself. Our professor emailed the group to ask whether he could use the report as the gold-standard example for future class sessions. He praised the structure, layout, and design, which mattered because good communication should be usable and visually clear. But the feedback that stayed with me most was about the substance: the thoughtfulness of the report, the grounded research, the plain-language writing, the use of data, and the way we positioned the recommendations.

He also encouraged us to submit the report to the Division of Student Affairs and other university leadership, so, in his words, “this valuable research and suggestions don’t go to waste.” He believed the research was strong, the recommendations were immediately relevant, and the work had value beyond the classroom.

That had been our intent from the beginning. But by that point, we had more than a completed assignment. We had a polished, research-backed recommendation report, institutional encouragement from a professor, and a specific leadership audience to bring it to.

Oftentimes, the issue is not that information does not exist. The issue is that the people who need it cannot access it, or that access depends on single points of failure. That kind of complexity can render information useless, even when it is timely, relevant, and polished.

When that happens, you do not always need to rewrite the information or create more content.

You need to rethink the systems, habits, culture, and workflows that govern how information moves. That was the problem behind this project. An engineering and installation company had valuable technical knowledge, but it was scattered: installation manuals, official parts documentation, random files, informal institutional knowledge, and unstandardized handoffs.

So what happened when field technicians needed an answer, or when the company needed to onboard a new hire?

A messy, undefined, redundant workflow cascade that depended too heavily on individual people knowing where things lived, who to ask, and how to interpret the answer.

This company worked on the installation and service of commercial equipment, including mechanical parts, control boards, and low-voltage wiring. As part of their daily work, teams and technicians would enter the field, visit customer sites, and attempt to complete the job: installation or service. But work continually stalled, wasting hours on site and leaving field teams, office staff, and customers frustrated.

At first glance, an outsider might blame incomplete training, workers who did not care about the outcome, a lack of preparedness, or persnickety customers.

As an information architect, I could see the real problem, in part because I had lived in a similar environment during my time as a locksmith technician.

When reliable access to technical information, installation guidance, equipment details, and knowledge of recurring processes is not formalized, the result is predictable: teams enter downtime while they wait on a single point of failure to rectify the problem. For this business, that meant waiting for a senior tech or the business owner to answer a phone call, waiting for office staff to forward a PDF to a technician’s phone or iPad, or sitting on hold with the manufacturer to reach an account executive.

Working from an outside-in perspective, the resolution was clear: field teams needed faster access to relevant information and multiple access points so work would not stall while waiting for a single resource to become available.

When I was brought on, the ask was essentially: “Help us teach techs so they do not have to call for every incident.”

By the time the project was finished, the work had expanded far beyond instructional design. It became an information architecture, change management, and workflow improvement project built around one practical goal: to help people find the answer before the work stopped.

The process started as instructional design. But as I began asking questions and interacting with the field techs, I quickly learned that most were already at a relatively advanced level in their training, knowledge, and capabilities. Good instructions would help new techs onboard. That would be a win! But those instructions would not address the core problem I had been brought in to solve. A loss!

So, I pivoted. I used lessons I had learned from other engagements to build a dependency map and organizational matrix using information gathered from field techs, office staff, and the owner.

With those resources in hand, the bottleneck became easy to see. Even better, it was not just qualitative. It was quantitative.

Step 1: Remove the bottleneck for acquiring PDFs and installation materials. I developed a strategy for a central repository that techs could access from their devices. Once that existed, they no longer had to wait for office staff to find and forward a manual. With a quick search, they could resolve it themselves.

Step 2: Reduce reliance on senior techs and the owner for repeated questions. This meant working with those individuals to turn informal, intangible knowledge into physical resources: flowcharts, “if this, then that” structures, and a few instructional videos. I started with the lowest-hanging fruit: the issues techs called about most often. From there, we moved up the chain based on frequency and workflow impact. Items that were rarely requested or took only a few seconds to resolve were pushed to the back of the documentation queue. Those that were repeat requests moved to the front. The completed artifacts were also added to the central repository.

Step 3: Build an organizational support flowchart. This clarified who was most proficient with specific equipment, who should not be contacted for certain issues, what pre-work techs could do before escalating, and how the escalation cascade should work from there. The cascade was structured around both speed and complexity. A five-minute call to a senior tech came long before a half-hour hold with the OEM or a manufacturer’s account executive.

Step 4: Structure office workflows around blocks. This helped streamline work, organize priorities, and create clearer handoffs between staff members and projects. It also helped with end-of-day closeout.

Step 5: Restructure new-tech training around the new system. Once the repository, flowcharts, support paths, and workflow blocks were in place, onboarding could be rebuilt around those resources rather than relying on informal memory, scattered files, or whoever happened to be available.

The result was a documentation and support system that reduced field technician call-ins by approximately 70% and shortened new-hire onboarding by one day.

But the numbers only tell part of the story. The bigger result was that the company no longer had to rely as heavily on memory, hallway knowledge, phone calls, scattered files, or a few overloaded people to keep work moving. Field techs had a central place to find manuals, installation materials, troubleshooting resources, flowcharts, and equipment-specific guidance. Office staff had clearer workflows and handoffs. Senior techs and the owner no longer had to worry that leaving for vacation meant the place might fall apart in their absence. New techs could be trained on an actual system rather than an informal maze.

The lesson was simple but important: the original problem was not a lack of effort, intelligence, or care. It was a system design problem. People were doing their best inside a workflow that made information too hard to access, too dependent on single points of failure, and too vulnerable to interruption.

Sometimes, the complexity of the information itself has already been flattened as far as possible without losing necessary context. At that point, the remaining issue is not the manual, guide, or resource. It is the complexity of access: where the information lives, who can reach it, how quickly they can find it, and whether the structure supports the way people actually work.

That engagement reinforced one of my core beliefs about communication. Sometimes the answer is not “write a better manual.” Sometimes the answer is to rebuild the process around how people actually search, learn, ask questions, escalate issues, and complete work. Good documentation does not just explain a system. Done well, it changes how the system and those inside it behave.

My technical writing work has focused on turning complex product, process, and engineering information into documentation that people can actually use. At one engagement, that meant working with engineers, safety teams, lifecycle managers, and documentation reviewers to create installation guidance, product bulletins, process documentation, and external-facing technical updates for warehouse automation systems. At another, it meant writing and revising web help, knowledge base content, interface text, and configuration guidance for enterprise cybersecurity products. Across both environments, the work required more than clean sentences. It required asking better questions, understanding the audience’s level of technical fluency, respecting review and approval workflows, and translating expert knowledge into accurate, accessible guidance.

A major thread in my work is the belief that communication matters most when people have the least room for error. That became especially clear while helping international J-1 workers navigate nonresident tax filing requirements. Many were trying to understand unfamiliar IRS forms, navigate language barriers, seek unclear institutional support, and contend with a predatory informal tax-preparation network exploiting their confusion. I learned the process, translated requirements into plain-language guidance, and helped people move through a system that was technically available but practically inaccessible. That experience shaped how I think about vulnerable populations, public trust, and the ethical responsibility to make complex systems legible before someone gets hurt by them. That conclusion is incredibly important in any scenario involving captive audiences (where no alternative exists).

Some of my strongest work has involved not just writing information, but structuring it so people can find, trust, and reuse it. For an engineering and installation client, I built a centralized documentation system that organized scattered technical knowledge into a clearer, more reliable source of truth. The result was a 70% reduction in field technician call-ins and a one-day reduction in onboarding time. That project sits at the heart of how I think about information architecture: the problem is not always that information is missing. Sometimes it exists in too many places, in too many formats, with too little structure. Good architecture turns scattered knowledge into a system people can actually navigate.

My communications work spans career services, copywriting, technical blogs, web content, email campaigns, instructional resources, instructional videos, and stakeholder-facing materials. In career services, I helped people translate messy work histories into clearer professional narratives. In copywriting and web content, I helped organizations explain what they did, who they served, and why it mattered. In technical blogs, instructional materials, and video-based learning content, I worked to make unfamiliar topics more approachable without flattening their meaning. Creating instructional videos requires many of the same skills as technical writing: understanding the audience, breaking complex processes into manageable steps, organizing information logically, and presenting it in a format that supports learning and retention. Across these projects, the common thread has been audience awareness: understanding who needs the information, what they already know, what they are trying to do, and what kind of communication will help them take the next step.

Some of the most useful communication work I’ve done has happened outside formal job titles. Volunteer and community settings have taught me how quickly information gaps become real barriers when people are navigating unfamiliar systems, limited resources, or high-friction decisions. That has shown up in different ways: helping international workers understand tax requirements, supporting youth and community programs, participating in trail and outdoor stewardship work, and contributing to public-health-oriented outreach abroad. 

Across those experiences, the lesson has been consistent: people need help. Help to understand, support when they're afraid or the way ahead is unclear, and what kind of communication they're willing to trust.

Across these different kinds of work, the method is largely the same: understand the system, understand the human inside the system, and build communication that helps the two interact more clearly.

A document, web page, guide, email, or video does not succeed just because it exists. It succeeds when it helps someone understand what matters, make a better decision, complete a task, avoid an error, adopt a change, or trust the process enough to keep moving. That is why I tend to work from the outside in: start with the person receiving the information, identify what they need to do, and trace backward through the process, stakeholders, constraints, and friction points.

That way of thinking has produced measurable and meaningful results: fewer repeated questions, reduced call-ins, faster onboarding, clearer handoffs, stronger recommendations, and more usable guidance for people navigating complex systems.