Case Studies | Bells and Whistles Designs

Case Study #1: Bells & Whistles · UI/UX Personal Project

Problem:
When I first launched Bells & Whistles Designs, it was essentially a static placeholder, a single page that existed only to “be there.” It didn’t communicate my skills, my thinking, or my growth as a developer and designer. More importantly, it couldn't evolve. Any update required manual changes with no clear structure, no narrative, and no sense of progression. The site only functioned as a snapshot in time rather than a reflection of how I actually work. I needed a portfolio that could grow with me not just visually, but structurally and conceptually.

Approach:
I reframed my portfolio as a living product, not a finished artifact. Instead of redesigning everything at once, I chose an iterative approach, treating the site as something that could be continuously improved: - Broke the site into reusable components (cards, sections, layouts) - Introduced an Archive to document work over time rather than hiding it - Designed clear distinctions between previews and full content - Implemented authentication flows to demonstrate real-world UX patterns Focused on clarity, readability, and intent over visual noise. Each change was incremental tested visually, refined, refined again, and then built upon. I intentionally avoided over-engineering and instead leaned into progressive enhancement.

Outcome:
Bells & Whistles Designs is now a structured, evolving portfolio that reflects how I actually think and build. The site communicates process, not just outcomes. - Authentication is used intentionally to demonstrate gated experiences - Case studies, blog posts, and weekly thoughts create a consistent narrative - DEmonstrations are real world scenarios - The archive serves as both documentation and discovery - The system is easy to extend without redesigning from scratch What began as a static, “do nothing” page has become a flexible platform for experimentation, reflection, and growth. One that mirrors how I can evolve in the real world.

Case Study #2: React · State · UI · Personal Project

Problem:
As my projects grew beyond static pages, I needed a clearer way to manage UI complexity and state. In vanilla JavaScript, even small interactions quickly became difficult to reason about, especially as components started to depend on shared data. I wanted a focused environment to explore how component-based architecture and state flow could simplify UI logic and improve maintainability.

Approach:
I built a small React demo with the explicit goal of understanding how data moves through an application, not just how components render. Key decisions included: Breaking the interface into small, reusable components Passing state intentionally through props to understand data ownership Using local state where appropriate to avoid unnecessary complexity Treating components as predictable, isolated units Prioritizing readability over cleverness Rather than reaching for advanced patterns immediately, I focused on mastering the fundamentals, component boundaries, state updates, and UI reactivity.

Outcome:
The React Demo clarified how component-based systems scale more cleanly than ad-hoc DOM manipulation. UI changes became predictable and traceable Components were easier to test and reason about State-driven rendering reduced manual updates The project formed a foundation for more complex React work This demo now serves as both a learning artifact and a reference point for future projects that require structured UI logic and shared state.

Case Study #3: API · Netlify · Functions

Problem:
The portfolio required a live RESTful API demo that could fetch and display real-time data without exposing sensitive API keys or breaking on static hosting platforms such as GitHub Pages. Direct client-side API calls were not suitable due to security and deployment limitations.

Approach:
Implemented a serverless backend using Netlify Functions to act as a secure proxy between the frontend and a third-party news API. API keys were stored as environment variables and never exposed to the client. The frontend was designed to consume normalized JSON responses and included environment-aware logic to gracefully handle static hosting scenarios.

Outcome:
Successfully deployed a production-ready API integration that works reliably across desktop and mobile devices. The solution demonstrates secure API consumption, serverless architecture, and clean separation of concerns, resulting in a scalable, maintainable, and professional-grade demo suitable for real-world applications.

Case Study #4: Client-Side Authentication · Session Handling

Problem:
Needed login/logout behavior without a backend server. Pages required conditional UI rendering. Session state had to persist across refreshes.

Approach:
Used localStorage for session persistence. Centralized auth checks in dashboard.js. Condition-based UI rendering (logout visibility). Redirect handling for protected pages.

Outcome:
Functional authentication flow. Clear separation of concerns. Scalable foundation for backend integration later.

Case study #5: Does my UI validate against real-world standards?

Problem:
Ensuring my portfolio was accessible, and usable. Is it aligned with modern web best practices? Across multiple pages?

Approach:
Ran Lighthouse audits across core pages (Home, Login, Dashboard). Evaluated accessibility, contrast, semantic structure, and interaction patterns. Addressed issues where appropriate without compromising design consistency.

Outcome:
Lighthouse Accessibility scores of 100 on public-facing pages. Dashboard Accessibility score of 95, with remaining items related to color contrast tradeoffs. 100 Best Practices score across audited pages. Accessibility considerations documented and maintained throughout development.