Portfolio Case Study
HP Printer Embedded
Web Server (EWS)
UI/UX Design Work
Designed and developed key sections of a browser-based printer configuration interface — improving usability, information hierarchy, and consistency across the product.
Company
HP (via Wipro)
Role
UX Engineer / UI Designer
Platform
Browser-based EWS
Scope
UX Design · UI Development · Frontend
Experience Level
Early Career (0–2 years)
Interface Reference
Key Screens Designed
These are the key screens I designed and implemented — spanning Home, Network, Web Services, and Settings within the EWS interface.
HP Ink Tank Wireless 410 Series — Embedded Web Server (EWS) · Interface Reference
Home Dashboard
Designed
✓
Clear status hierarchy: ink, connectivity, alerts
✓
Quick action discoverability
Network Config
Designed
✓
Progressive field disclosure by mode
✓
Password visibility control
Web Services
Designed
✓
Plain-language context before action
✓
Prominent enable/disable CTA
Settings
Designed
✓
Consistent button hierarchy system
✓
Unified section structure
02
Context & Problem
A Complex Interface Serving
Two Very Different Users
The Embedded Web Server (EWS) is a browser-based configuration panel that lives inside the printer itself — accessible over the local network without any app installation. It serves both everyday home users trying to connect their printer to Wi-Fi and IT administrators managing fleets of devices.
The interface carried layers of accumulated complexity: multiple nested tab levels, dense forms, inconsistent component usage, and very little hierarchy to guide the user's eye. My work involved designing clearer, more structured solutions across the key screens users interacted with most.
HP
|
Ink Tank Wireless 410 series
Embedded Web Server
Network configuration — form layout designed with progressive disclosure
01
From Static Overview to Action-Oriented Dashboard
Home
Static dashboard with fixed modules.
No prioritization of frequently used actions.
Equal visual weight for informational and actionable cards.
No personalization for different user types.
Limited adaptability across usage scenarios.
02
Introducing Structured Levels for Faster Navigation
Settings grouped without strong hierarchy.
Advanced and basic configurations visually similar.
Hard to quickly locate specific controls (IP, DNS, Wi-Fi Direct).
Long configuration pages with minimal grouping.
High risk of misconfiguration due to poor separation of critical settings.
03
Introducing a Missing Capability
Not consistently available or clearly structured across models.
Service state visibility unclear.
Enable/disable controls lacked emphasis.
Text-heavy explanations reduced clarity.
04
Reducing Clutter in System Information
Dense information tables.
Critical status information mixed with secondary metadata.
Limited visual hierarchy.
High cognitive load for scanning system details.
05
Poor Feedback States
Inconsistent spacing and component structure.
Weak CTA hierarchy.
Status indicators lacked visual prominence.
Limited scalability for future features.
03
My Responsibility
Owning UX and Frontend
Execution Across Multiple Screens
"While senior stakeholders defined feature scope, I owned the UX design and frontend implementation for multiple screens — from audit and design exploration through to working production code."
UX Design
Conducted full UX audit across all EWS tab sections
Documented usability issues and design constraints with annotated screenshots
Designed Dashboard, Wireless Setup, Wi-Fi Direct, Web Services, and Settings screens
Established clear information hierarchy and visual grouping across modules
Standardised UI components: buttons, forms, tables, and interaction states
Defined visual feedback patterns for success, error, and loading states
Worked within HP's existing design constraints and brand guidelines
Frontend Implementation
Converted designed layouts into working frontend code
Implemented pixel-accurate UI within the embedded browser environment
Maintained cross-browser compatibility (IE, Chrome, Firefox)
Worked within embedded system resource and performance limits
Fixed usability and rendering bugs reported from QA and field testing
Collaborated with firmware engineers to align frontend and backend state
Screens I Owned
Dashboard
Designed
Wireless Setup Wizard
Designed
Wi-Fi Direct
Designed
Web Services
Designed
Network Summary
Improved
Settings Pages
Improved
Product Information
Improved
04
UX Design Work
Four Core Areas
of UX Design
Each area was approached with a structured UX audit, design exploration, and final implementation. Below are the design challenges I was solving and the decisions I made for each section.
A
Dashboard
B
Network & Wireless
C
Web Services Setup
D
Consistency & System
A
Dashboard
Information Architecture & Status Clarity
?
Design Challenge
The dashboard needed to serve two very different users simultaneously: home users who just wanted to see if their printer was ready, and power users who needed detailed system metrics. Presenting all information at equal weight served neither.
-
Ink levels, network status, and device info competed for equal attention
-
No visual path from status overview to the action a user needed to take
-
Critical alerts were not visually differentiated from passive information
-
Card sizing and padding were inconsistent, making scanning difficult
✓
Design Decision
Grouped content into logical clusters — printer status, connectivity, and quick actions — with a clear visual hierarchy that surfaced the most critical information first and let users drill deeper as needed.
✓
Organised system info into thematic sections with clear labels
✓
Elevated critical status indicators with colour coding and iconography
✓
Applied consistent card sizing and whitespace to aid scanning
✓
Created a clear visual path from status to the relevant action
Design principle: Hierarchy over completeness — show what matters first, let users dig deeper when needed.
B
Network & Wireless
Form Simplification & Configuration Flows
?
Design Challenge
Wireless setup is the most critical first-time task for any printer user, but the configuration flow was buried inside nested sub-tabs, with all advanced options exposed simultaneously regardless of the user's actual setup scenario.
-
The Wireless Setup Wizard entry point was not prominent on the page
-
IPv4 and IPv6 fields were displayed simultaneously regardless of mode
-
Password field lacked a visibility toggle, leading to input errors
-
Error and success states used raw technical messages with no guidance
✓
Design Decision
Elevated the Wireless Setup Wizard as the dominant action on the page, simplified forms to show only contextually relevant fields, and introduced clear human-readable feedback for all state transitions.
✓
Made the Wireless Setup Wizard a prominent, visually distinct CTA
✓
Conditionally revealed IPv4 or IPv6 fields based on user selection
✓
Added password visibility toggle to reduce input errors
✓
Designed clear, friendly success and error message patterns
Design principle: Progressive disclosure — surface only what's relevant to the user's current configuration choice.
C
Web Services Setup
Enablement Flow & Jargon Reduction
?
Design Challenge
Enabling HP Web Services is a key activation step for cloud printing features, but users were presented with a complex technical flow without enough context to understand what they were enabling or why it mattered.
-
No plain-language explanation of what Web Services actually enables
-
The enable/disable action lacked visual prominence on the page
-
State change confirmation was absent or unclear after action completion
-
Terms like "ePrint" were used without context or definition
✓
Design Decision
Added a brief, benefit-focused plain-language introduction, made the enable action the dominant element on the page, and ensured every state change was immediately confirmed with a clear, visible response.
✓
Added a concise explainer above the enable action covering key benefits
✓
Made the enable/disable button the most prominent element on the page
✓
Designed a clear confirmation banner shown immediately on state change
✓
Linked technical terms to contextual inline tooltips for clarity
Design principle: Context before action — users need to understand what they're enabling before they enable it.
D
Consistency & System
Component Standardisation Across All Screens
?
Design Challenge
Without a shared component system, each section of the EWS had been built with its own visual conventions. Buttons, tables, form fields, and spacing varied across pages, creating a fragmented experience that undermined trust and usability.
-
Button styles varied across sections — flat, bordered, and styled inconsistently
-
Tables lacked uniform column alignment and row spacing standards
-
Disabled states were visually indistinguishable from active states
-
Section headers used no consistent typographic scale across modules
✓
Design Decision
Defined a shared set of component patterns — button hierarchy, table structure, form layout, spacing, and state definitions — and applied them uniformly across all screens I owned, creating a more cohesive product feel.
✓
Established primary, secondary, and ghost button styles with clear hierarchy
✓
Unified table row/column spacing and alignment across all data views
✓
Clearly differentiated enabled, disabled, and loading/error states visually
✓
Applied a consistent typographic scale and section header treatment
Design principle: Systems thinking — a small set of well-defined components reduces cognitive load across the entire product.
05
Frontend Development
From Design
to Production Code
One of the more valuable aspects of this project was that I didn't just design screens — I also implemented them. Working across both disciplines gave me a strong understanding of where design and engineering intersect.
The embedded nature of the EWS created real constraints: the interface had to function on minimal compute resources, load quickly over a local network, and render correctly across browser environments that included much older legacy versions.
Key Career Insight
"This experience strengthened my understanding of design feasibility and technical constraints early in my career. Being the person who both designed and built the UI removed ambiguity — and made me a much more practical designer."
Technologies & Constraints
HTML5
CSS3
JavaScript (ES5)
Responsive CSS
Cross-browser testing
Embedded HTTP server
Form validation
Browser state management
Design-to-Code Implementation
Converted UX designs and wireframes into working HTML/CSS frontend code, maintaining pixel-level fidelity to the approved layouts.
Embedded System Constraints
Worked within the strict constraints of a printer's embedded HTTP server — limited memory, no modern build tools, and minimal JavaScript runtime support.
Cross-Browser Compatibility
Ensured the interface worked correctly across multiple browser versions including legacy Internet Explorer, Chrome, and Firefox — a common constraint for enterprise device UIs.
Firmware Engineer Collaboration
Worked closely with firmware engineers to align frontend state changes (success/error/loading) with actual backend API behaviour, ensuring the UI reflected real device state accurately.
Bug Resolution in Production
Identified and resolved 100+ UI issues surfaced through QA cycles and field testing, including rendering inconsistencies, alignment bugs, and state management gaps.
Feasibility-Aware Design
Because I was both designing and implementing, I could quickly validate design decisions against technical constraints — avoiding solutions that would be impossible to build within the embedded environment.
06
Challenges Faced
Real Constraints, Real
Problem-Solving
This project required navigating legacy systems, embedded hardware limits, and cross-functional complexity. These constraints shaped how I approach design problems today.
Technical
Embedded System Performance Limits
The EWS runs on the printer's internal processor with very limited resources. Every UI decision — number of DOM elements, image sizes, JavaScript complexity — had to be weighed against performance impact. Modern UI patterns that rely on heavy scripting were simply not options.
Architecture
Working Within Legacy Architecture
The codebase had years of accumulated technical debt. Making meaningful UX improvements often meant working around — not against — existing backend structures. Some ideal UX patterns were constrained by what the underlying system could actually support.
Design
No Formal Design System
There was no existing design system or component library to reference. UI patterns varied across screens because each section had been built at different times by different teams. Establishing consistency required auditing everything from scratch and proposing common patterns.
Cross-functional
Balancing UX Changes with Backend Logic
Several UX improvements — like conditionally showing form fields based on user selection — required close coordination with firmware engineers to ensure the frontend changes didn't break backend validation or state management. I had to understand the backend constraints deeply enough to design around them.
Communication
Communicating Design Intent to Engineers
Early in my career, I had to develop the vocabulary and artefacts to clearly communicate UX decisions to engineers who were more focused on functionality than presentation. I learned to annotate designs with explicit rationale and to frame UX choices in terms of user impact, not aesthetics.
Research
Designing Without User Research Access
Direct user research access was limited in this context. Design decisions were informed primarily by heuristic evaluation, internal QA feedback, and field-reported issues. I learned to build strong reasoning from available signals rather than waiting for ideal conditions.
Reflection
Every challenge here taught me something I still carry. Working inside constrained, legacy systems forces disciplined prioritisation — you cannot solve everything at once, so you learn to identify what will have the most meaningful impact within real boundaries. That mindset has made me a more pragmatic designer.
07
Outcomes & Impact
Grounded, Measurable
Outcomes
The outcomes of this project were practical and visible — not sweeping, but meaningful for users, engineers, and the product team.
100+
UI & Usability Issues Resolved
Across QA cycles and production deployments
7
Dashboard, Wireless, Wi-Fi Direct, Web Services, Network, Settings, Product Info
4
Core UX Areas Owned
Dashboard, Network Config, Web Services, Consistency system
2x
Roles Covered
Designed and implemented — reducing back-and-forth between teams
◈
Improved Visual Consistency Across Modules
By establishing shared component patterns for buttons, tables, form fields, and states, the interface started to feel like a cohesive product rather than a collection of independently-built pages.
◈
Reduced User Confusion in Network Flows
The simplified wireless setup flow and clearer error handling reduced the number of field-reported configuration issues. Users had a clearer path through the most critical printer setup task.
◈
Improved System Status Clarity
The dashboard design surfaced printer status, connectivity, and ink levels with appropriate visual hierarchy — reducing the time it took users to understand the printer's current state at a glance.
◈
Stronger Design-Engineering Collaboration
Working across both roles helped build a shared language between design and firmware teams. Annotated design handoffs became a standard part of the workflow on this project.
A Note on Scope
These were early-career contributions made within a large product team. The impact was real but bounded — improvements to specific flows, not a full product transformation. The goal was always to make meaningful progress within real constraints, not to claim ownership of outcomes beyond my scope.
08
What I Learned
This was an early-career project, and that's exactly what makes it worth reflecting on. The lessons here weren't learned in a classroom or a side project — they came from doing real work inside a real product, with real constraints, alongside real engineers and stakeholders.
Growth Through
Real Constraints
01
Designing for Hardware-Constrained Environments
This project taught me that great UX isn't always about the latest patterns — it's about understanding the real environment your interface lives in. Designing for an embedded system forced me to think carefully about performance, load time, and what "interactive" actually means when resources are scarce.
02
The Importance of Clear System Feedback
Watching users encounter silent failures or cryptic error messages made clear how critical good feedback states are. I came away with a deep appreciation for success confirmations, loading indicators, and human-readable error messages — things that are easy to overlook but matter enormously to users.
03
Writing UX Copy for Technical Products
Technical products often have jargon baked into their very architecture — field names, state labels, error codes. Learning to rewrite these for clarity without losing accuracy was one of the most valuable writing skills I developed. Good UX copy is the invisible work that makes complex products approachable.
04
Bridging Design and Engineering
Being the person who both designed and built the UI gave me a perspective that's hard to develop otherwise. I understood the engineering perspective from the inside — not just as a stakeholder. This shaped how I write design specs, communicate decisions, and evaluate feasibility to this day.
05
Thinking Beyond Visuals into Implementation
The shift from "does this look right?" to "can this actually be built, and how?" happened naturally when I was responsible for both. I learned to design with implementation in mind — not as a constraint, but as part of the creative brief itself.
06
Working Effectively Inside Legacy Systems
Real products aren't greenfield. They have history, constraints, and accumulated decisions that can't be undone overnight. This project taught me to audit systematically, prioritise ruthlessly, and find ways to make meaningful progress even when you can't start from scratch.
Starting Point
At the start of this project, I was a UX engineer learning to translate designs into code. I could execute tasks, but struggled to own the full picture — from problem to solution.
After This Project
I left this project with a much clearer sense of what it means to own a UX problem end-to-end. I could audit an interface, identify the right design approach, execute practical solutions, and ship them — while navigating real technical and organisational constraints along the way.
This case study represents work completed in the first two years of my career. It reflects execution and growing ownership — not senior-level strategic leadership. That honesty is intentional.
Get Athos Pro