Building TechTidy

01 — Starting with the problem

People are not the problem.

Across technical support, systems work, education, and training, I kept seeing the same pattern: people blamed themselves when technology was confusing. Usually, the real problem was that the explanation assumed too much, arrived without context, or focused on clicks instead of understanding.

TechTidy began with a simple question: How can technology learning make people feel more capable rather than more dependent?

That question shaped the audience, tone, structure, and technical choices for the site.

02 — Defining the learning experience

A clear path matters as much as accurate information.

The early site contained useful material, but the relationship between articles was not always obvious. I reorganized the content into learning paths so visitors could begin with a need and progress at their own pace.

03 — Building the system

Simple technology, deliberately used.

TechTidy is built with semantic HTML, CSS, and lightweight JavaScript. A static architecture keeps the site fast, inexpensive, and easy to maintain while reducing unnecessary technical complexity.

04 — Designing for access

Accessibility is part of the learning design.

A learning resource cannot be called approachable if the site itself creates avoidable barriers. The design therefore prioritizes readable contrast, keyboard focus, semantic headings, descriptive links, responsive layouts, plain labels, and generous spacing.

The dark and light themes support personal preference, but the content remains available without JavaScript. Mobile layouts are treated as a primary reading experience rather than a compressed desktop page.

Good technical training does not show people how much the author knows. It helps them see what they can do next.

05 — Working with AI responsibly

AI accelerated the work; it did not own the decisions.

I used AI as a development and review partner: testing alternative explanations, identifying unclear structure, troubleshooting code, and challenging design assumptions. That shortened feedback loops, but it also required active verification.

I remained responsible for the audience, facts, editorial judgment, privacy decisions, technical implementation, and final quality. This approach became part of the site’s wider teaching philosophy: AI is most useful when it strengthens human thinking rather than replacing it.

06 — Iterating in public

The site is a working product, not a finished brochure.

Content and navigation have changed as the purpose became clearer. Early business-style language gradually gave way to a stronger community-learning focus. Articles were consolidated into learning paths, dead ends were replaced with next steps, and the Digital Confidence program connected individual lessons to a facilitated experience.

That iteration is intentional. It demonstrates the same adoption process I use in technical work: listen, identify friction, make a controlled change, validate it, document it, and improve again.

07 — What the project demonstrates

One project, several connected disciplines.

• Audience analysis: defining content around learner needs instead of tool features.
• Curriculum design: turning individual resources into progressive learning paths and an eight-week program.
• Technical communication: translating AI, cloud, databases, and cybersecurity into plain language.
• Technology adoption: connecting explanation, practice, support, and reinforcement.
• End-to-end delivery: moving from research and writing through design, development, analytics, deployment, and maintenance.
• Continuous improvement: using feedback and evidence to make the experience clearer over time.

08 — What comes next

Move from information to participation.

The next stage is to deepen the Digital Productivity path, test the Digital Confidence program with community partners, and gather structured learner feedback. The goal is not to publish the most content. It is to make each resource genuinely useful and each learning step easier to take.