Inspiration

Hmingportfolio began with a simple problem: a conventional portfolio can display polished screens, but it often fails to show how a designer actually thinks, collaborates, makes trade-offs, and brings a product closer to implementation.

The portfolio needed to communicate more than visual craft. It had to represent a multidisciplinary product-design practice shaped by art, mechanical engineering, project management, HCI research, and hands-on UI/UX work. These experiences led to a design perspective that consistently balances three forces:

User needs
Business goals
Engineering feasibility

We were also inspired by a broader shift in product design. AI is no longer only a tool for generating isolated ideas or interface variations. When used deliberately, it can become a working partner across:

Research synthesis
Content structuring
Front-end prototyping
Implementation review
Quality assurance

The goal was therefore not simply to create a portfolio containing AI-related projects, but to build the portfolio itself through a transparent human–AI collaboration model.

The designer remains responsible for defining the problem, deciding what should be built, evaluating whether the output is accurate, and determining whether it represents the intended product story.

AI agents support the execution layer by:

Analyzing existing patterns
Proposing structures
Implementing components
Identifying regressions
Accelerating repetitive validation work

This approach reflects the same principle shown throughout the portfolio’s case studies: technology is valuable only when it supports a clear human decision.

In the Advantech project, for example, generative AI was reframed from a passive chatbot into a decision-support layer that proactively delivers relevant analysis and actions.

That same philosophy shaped hmingportfolio:

AI should not replace design judgment. It should help that judgment move further and become more executable.

What it does

Hmingportfolio is a bilingual product-design portfolio that presents selected work across:

Enterprise AI
FinTech
Web3
Design systems
Human–computer interaction

Its primary purpose is to help recruiters, hiring managers, designers, engineers, and product stakeholders understand not only what was designed, but also:

What product or business problem existed
Who experienced the problem
How the problem was framed
What research changed the original assumptions
How design decisions were made
How technical constraints influenced the solution
What impact or validation evidence was available
What the designer learned from the project

The home page introduces a product-design profile positioned at the intersection of user insight, business goals, and engineering feasibility.

It then directs visitors toward selected industry and academic projects, including:

An AI-supported facility-management platform
A quantitative trading product
A Web3 digital-credential service

Each case study is structured as a product narrative rather than a gallery of final screens.

The stories connect:

Product context
User problems
Research
Strategic decisions
Interaction flows
Iterations
Final interfaces
Impact
Reflections

For example, the Advantech case study explains how fragmented energy and equipment data across EcoWatch, HVAC, and multiple facilities made it difficult for facility teams and system integrators to identify priorities.

The resulting concept uses generative AI as a cross-system decision entry point for:

Demand analysis
Overage alerts
Anomaly diagnosis
Troubleshooting guidance

The Crypto Arsenal case study shows how traders previously had to leave the quantitative-trading platform and return to an exchange to close positions or configure take-profit and stop-loss controls.

The redesigned experience brings these actions directly into the strategy workflow, reducing average completion time across three tested tasks from 65 seconds to approximately 27 seconds.

The portfolio also contains a public design-system reference.

This documents the actual foundations and components used by the live website, including:

Colors
Typography
Spacing
Motion
Navigation
Form controls
Project cards
Case-study structures
Media components
Feedback states
Component-boundary guidance

Rather than forcing every case study into an identical template, the system uses a two-layer architecture.

Reusable system layer

The reusable system layer includes:

Design tokens
Global navigation
Interface primitives
Project-card behavior
Stable case-study components

Local storytelling layer

The local storytelling layer includes:

Diagrams
Matrices
Workflow maps
Scenario boards
Media crops
Project-specific visual structures

This allows the website to remain visually and behaviorally consistent while preserving the individual character and informational needs of each project.

How we built it

We built hmingportfolio as an evolving product rather than a one-time collection of static portfolio pages.

The process began by defining the portfolio’s product goal:

Help a reviewer quickly understand the designer’s role, reasoning, contribution, collaboration model, and product impact.

From there, we treated every case study as an information-architecture and product-storytelling problem.

1. Content and narrative architecture

We reviewed each project and reorganized it around the decisions a hiring team would need to evaluate:

What was the initial situation?
What was the core problem?
Who was affected?
Why did the problem matter to the product or business?
What did the designer own?
What evidence informed the solution?
What changed through iteration?
What was validated?
What remained unresolved?

This moved the case studies away from chronological activity logs and toward outcome-oriented product narratives.

Shared structures were standardized where their semantic responsibilities remained stable, including:

Project hero
Project overview
Section headers
Outcome walkthroughs
Cards
Media containers
Before-and-after comparisons
Navigation patterns

Project-specific diagrams and visual explanations remained local when generalizing them would reduce clarity or create overly complicated component APIs.

2. A portfolio-derived design system

Instead of creating an aspirational design system disconnected from the implementation, we audited the website’s actual styles and components.

We identified recurring values for:

Color
Typography
Spacing
Border radius
Shadows
Motion

These values were then organized into traceable design tokens.

This meant visual adjustments could follow shared rules instead of being recreated independently on each page.

We also documented the intended boundaries of reusable components.

A repeated visual pattern did not automatically become a global component. It became shared only when its:

Purpose
Behavior
Content model
Responsive requirements

were stable across multiple contexts.

The resulting system is guided by several principles:

Define the design character before adding decoration
Allow project colors to change while keeping the structural frame consistent
Reserve accent colors for meaningful actions and active states
Use motion to clarify hierarchy rather than create spectacle
Preserve breathing room even in information-dense case studies
Express design decisions as maintainable specifications
Account for reachable states such as hover, focus, active, loading, disabled, and unavailable content

3. Responsive and bilingual implementation

The site was designed for both English and Traditional Chinese.

This required the content model and layout to support different text lengths rather than treating translation as an afterthought.

Responsive behavior was handled across:

Desktop
Tablet
Mobile

Dense case-study sections, interactive flows, tables, media, long titles, and project metadata required individual attention because simply shrinking a desktop layout would have made the stories difficult to read.

The interface therefore combines shared responsive rules with route-specific adjustments where each project’s visual material requires a different treatment.

4. Human–AI development workflow

The implementation was developed through a collaborative workflow between the designer and AI agents.

The designer was responsible for:

Defining the product and storytelling goals
Deciding the information architecture
Approving visual and interaction directions
Identifying which patterns should be reusable
Evaluating whether generated output matched the intended design
Reviewing the website manually
Making final quality decisions

AI agents supported:

Codebase analysis
Component and token audits
Implementation planning
Front-end development
Content-structure analysis
Localization checks
Responsive regression detection
Build and lint verification
Debugging
Implementation review

Work was broken into bounded changes rather than allowing an agent to redesign the entire site autonomously.

Each task included constraints around:

Scope
Reusable-component boundaries
Routes that could be modified
Validation requirements

This process made the AI collaboration auditable.

The system did not rely on a single generated result being correct. Quality emerged through repeated cycles of:

Analysis
Implementation
Automated checks
Visual inspection
Revision

5. Quality-control loop

The portfolio was continuously checked through multiple layers:

Content review for clarity, evidence, and recruiter relevance
Component review for appropriate reuse and stable APIs
Design-token checks for visual consistency
Responsive checks at representative desktop, tablet, and mobile widths
Horizontal-overflow detection
Linting and production builds
Interaction and state validation
Bilingual content review
Manual visual inspection of affected routes

The central principle was:

AI-generated implementation must be treated as a proposal, not as proof of correctness.

The result only passed when it:

Met the original design objective
Behaved correctly
Remained maintainable
Preserved unaffected parts of the website

Challenges we ran into

Turning several years of work into clear product stories

The original material contained:

Research
UI screens
Project activities
Technical context
Stakeholder feedback
Personal reflections

The challenge was deciding what a recruiter actually needed to understand and what could be removed.

Showing every artifact created long and fragmented pages.

Showing only final screens removed the reasoning that made the work valuable.

We had to establish a hierarchy that connected:

Problem
Decision
Evidence
Solution
Impact

without making each project feel like a research archive.

Separating project impact from product claims

Not every project had the same level of validation or market exposure.

Some work was shipped and internally tested. Some was an early-stage proof of concept. Some outcomes were based on stakeholder acceptance or implementation planning rather than public product metrics.

We had to distinguish carefully between:

Demonstrated usability results
Internal validation
Stakeholder feedback
Concepts accepted for further planning
Features that entered engineering development
Long-term product opportunities

This prevented the portfolio from overstating impact while still communicating the value of the design work.

Designing a shared system without flattening every case study

The projects span:

Industrial energy management
Quantitative trading
Digital credentials

They contain very different types of information, visual assets, workflows, and domain concepts.

Making everything local would create duplicated styles and inconsistent behavior.

Making everything shared would produce rigid components filled with exceptions and conditional logic.

The solution was to define stable reusable contracts for common case-study structures while keeping narrative-specific geometry close to the project that uses it.

This reusable-versus-local boundary became one of the most important architectural decisions in the website.

Maintaining responsiveness across dense content

Portfolio case studies frequently contain:

Wide flows
Comparison tables
Diagrams
Dashboards
Videos
Annotated interfaces

These elements do not naturally fit narrow screens.

The challenge was not merely avoiding horizontal overflow.

We also needed to preserve:

Reading order
Visual relationships
Captions
Touch targets
The meaning of each diagram

Some sections could use a shared grid or media wrapper.

Others required:

Scrolling guidance
Project-specific stacking behavior
Custom crop rules

Supporting two languages consistently

English and Traditional Chinese differ significantly in:

Sentence length
Word wrapping
Punctuation
Information density

A section that looked balanced in one language could become cramped or visually disconnected in the other.

The implementation therefore had to support content expansion and maintain parallel information architecture without forcing literal line-by-line symmetry.

Localization also required consistent translation of terminology across:

Product design
Engineering
AI
FinTech
Web3

Preserving accuracy while using AI

AI could quickly propose component abstractions, rewrite content, or modify multiple routes, but speed also introduced risk.

Common problems included:

Abstracting a pattern too early
Changing unrelated shared styles
Simplifying domain-specific content too aggressively
Producing confident but unsupported project claims
Solving one viewport while breaking another
Creating inconsistencies between English and Chinese
Describing AI contributions as though all execution had been performed manually by the designer

To address this, tasks were tightly scoped and every output was reviewed against:

The live design
Project evidence
Implementation constraints
Validation results

Explaining complex domains without overwhelming visitors

The projects involve:

Energy-demand rules
Equipment anomalies
Quantitative trading
Take-profit and stop-loss logic
Decentralized digital credentials

The challenge was to provide enough context for a recruiter unfamiliar with the domain while avoiding lengthy textbook explanations.

We solved this through layered communication:

Concise overview statements
Diagrams
Workflow explanations
Interface details
Optional deeper context

Accomplishments that we're proud of

We turned the portfolio into evidence of product thinking

The website does not rely only on polished visual output.

It demonstrates:

How problems were framed
How assumptions changed
How technical constraints were handled
How design decisions connected to users and business outcomes

The Advantech case shows the progression from fragmented energy data toward proactive decision support.

The Crypto Arsenal case connects:

User control
Platform retention
Trading logic
Measurable task-efficiency improvement

We created a functioning design system from the real product

The public design-system page documents the:

Tokens
Components
States
Patterns
Architectural decisions

actually used by the portfolio.

It is not simply a decorative component gallery.

It explains:

When a component should be reused
When a pattern should remain project-specific
How the system maintains consistency without erasing project character

We made human–AI collaboration part of the product practice

Instead of using AI only to generate copy or isolated code snippets, we incorporated it across:

Analysis
Prototyping
Implementation
Debugging
Validation

More importantly, we established a clear division of responsibility.

AI accelerated execution, while the designer retained ownership of:

Intent
Prioritization
Design judgment
Quality

The resulting portfolio demonstrates not only the use of AI tools, but also a repeatable framework for controlling their output.

We preserved distinct project identities within one coherent experience

Each case study can adopt its own:

Visual tone
Information density
Storytelling devices

while still feeling like part of the same portfolio.

The following remain consistent:

Navigation
Hierarchy
Cards
Typography
Spacing
Interaction states
Case-study foundations

Project-specific diagrams and presentation methods provide enough flexibility to communicate each domain effectively.

We connected design decisions with measurable or verifiable evidence

The Crypto Arsenal redesign was evaluated with five internal participants who had futures-trading experience.

Across the following tasks:

Limit close
Market close
Take-profit and stop-loss

average completion time fell from 65 seconds to approximately 27 seconds, representing a 58% reduction.

The overall usability score was 77.5 out of 100.

For projects without equivalent quantitative evidence, the portfolio identifies other forms of validation, such as:

Stakeholder review
Concept acceptance
Implementation progress
Prototype feedback
Clearly stated next steps

We made complex work easier to evaluate

The portfolio provides multiple levels of entry:

A concise positioning statement on the home page
Short project summaries for rapid scanning
Structured overviews of problem, goal, and impact
Outcome walkthroughs for understanding the proposed experience
Detailed case-study sections for deeper evaluation

This supports both:

A recruiter scanning for relevance
A product or design interviewer assessing the reasoning behind the work

What we learned

A portfolio is itself a product

Its users have:

Goals
Limited attention
Different levels of domain knowledge
Specific decisions to make

Recruiters need to identify fit quickly.

Design managers need to evaluate reasoning and craft.

Engineers and product managers may look for feasibility and collaboration.

A successful portfolio must therefore prioritize information and guide different audiences toward the evidence they need.

Strong storytelling is based on causality, not chronology

A list of activities such as research, wireframes, prototypes, and meetings does not explain why the final design exists.

A stronger story shows:

What problem existed
What evidence revealed
What decision followed
How that decision changed the product
What result or remaining question emerged

This causal structure made the work easier to understand and reduced the temptation to include every process artifact.

Reuse should follow stable responsibility

Visual similarity alone is not enough reason to create a shared component.

A component becomes reusable when its:

Semantic purpose
Content model
Interaction behavior
Responsive contract

remain stable across contexts.

When geometry is inseparable from a project-specific explanation, keeping it local can be more maintainable than forcing it into a universal abstraction.

AI requires more—not less—design judgment

AI reduces the time required to generate options and implement changes, but it also increases the number of plausible-looking outputs that must be evaluated.

The critical skill is therefore not producing more material.

It is:

Defining constraints
Identifying failure conditions
Reviewing evidence
Deciding what should be accepted

This mirrors a lesson from the Advantech case study: AI trust depends on controlled boundaries and expert feedback.

Outputs should support professional judgment rather than present themselves as unquestionable answers.

Proactive assistance is often more useful than an empty prompt

The Advantech research challenged the assumption that users would always know when to open a chatbot and what question to ask.

That insight also influenced the portfolio experience.

Important information should be surfaced in context through:

Hierarchy
Summaries
Walkthroughs
Visual cues

rather than requiring visitors to search for every answer themselves.

Domain rules must become interface assumptions that can be tested

Whether dealing with:

Electricity-demand intervals
Equipment alarms
Trading directions
Order types
Credential verification

domain knowledge cannot remain as abstract background information.

It must be translated into specific:

Interface behaviors
States
Labels
Data requirements
Edge cases

that designers and engineers can review together.

Validation must match the project stage

Not every project can produce live business metrics.

Early concepts may be validated through:

Stakeholder alignment
Feasibility review
Prototype testing
Implementation commitment

Shipped product flows may support:

Usability metrics
Task-performance comparisons
Product analytics

The important lesson was to state the level of evidence precisely rather than using the same definition of “impact” for every project.

Quality comes from a system of checks

No individual review method is sufficient.

Visual inspection can miss implementation issues.

Automated checks can pass while the narrative remains unclear.

A design system can maintain consistency while still allowing inaccurate content.

AI review can identify patterns but misunderstand intent.

Reliable quality therefore requires several complementary checks:

Content
Visual design
Responsive behavior
Component architecture
Implementation correctness
Localization
Human judgment

What's next for hmingportfolio

Expand the portfolio beyond presentation into interactive evidence

Future case studies can include:

Richer prototypes
Annotated interaction demos
Before-and-after comparisons
Focused decision walkthroughs

The objective is not to add more decoration, but to let visitors inspect the relationship between a problem, a design decision, and the resulting behavior more directly.

Complete and deepen the remaining case studies

The Web3 digital-credential project can be expanded into a complete public case study covering:

Issuers
Applicants
Verifiers
The research shift from feature validation to exploratory interviews
The correction of the team’s original assumptions
Compliance constraints
Usability testing
The end-to-end credential journey

Academic, community, and side projects can also be added selectively when they reveal capabilities not already demonstrated by the industry projects.

Document the AI collaboration system more explicitly

A dedicated case study can explain:

How design decisions are separated from AI execution
How tasks are routed between different agents or models
How prompts and constraints are structured
How generated code is reviewed
How regressions are detected
How quality gates work
How the workflow adapts as AI models and tools change

This would allow the portfolio to answer a growing hiring question:

Not merely whether a designer uses AI, but whether they can use it responsibly and repeatedly to produce reliable work.

Strengthen accessibility

Future iterations can expand:

Keyboard testing
Screen-reader semantics
Focus management
Motion preferences
Contrast checks
Accessible captions
Alternative explanations for complex visual diagrams

Accessibility should become part of the shared component contract and validation workflow rather than a final-page checklist.

Improve performance and media delivery

The case studies contain many:

Screenshots
Diagrams
Animations
Videos

Future work can optimize:

Image formats
Responsive media sizes
Loading strategies
Poster frames
Progressive rendering

Performance budgets can be established so visual storytelling remains rich without making the portfolio slow or unstable.

Add automated visual-regression coverage

Automated screenshots can compare key:

Routes
Languages
States
Viewport widths

after shared-component or token changes.

This would supplement manual review and make it easier to detect subtle regressions across long case-study pages.

Expand design-system governance

The design-system reference can evolve with:

Component maturity and status labels
Accessibility requirements
Usage and anti-pattern examples
Migration guidance
Contribution criteria
Deprecation rules
Clearer extraction thresholds for patterns currently kept local

The system should remain derived from real product needs rather than growing into an inventory of hypothetical components.

Improve portfolio analytics and recruiter feedback loops

Privacy-conscious analytics can help identify:

Which projects recruiters open
How far visitors progress through a case study
Where they leave
Which interactions receive attention
Whether users reach the resume or contact actions

These signals, combined with interviews or feedback from recruiters and design managers, can guide future content prioritization.

Continue evolving the site as a Product Builder platform

The long-term direction is for hmingportfolio to become more than a record of completed design work.

It can become a living platform that demonstrates the full path from:

Research
Product framing
Interface design
Design-system architecture
AI-assisted implementation
Validation
Continuous iteration

The next version should make that end-to-end capability increasingly visible:

Not only designing what a product should be, but also building enough of it to test whether the idea truly works.

Built With

ai-assisted
design
human-ai
interaction
portfolio
system