Marco Lozano
Data-dense products, designed and proven working.
I'm a Senior Product Designer focused on turning complex requirements into products that teams can understand, build and scale.
Over the past 16 years, I've worked across SaaS, micro-SaaS, enterprise and government platforms, often in environments where business requirements, technical constraints, accessibility and multiple stakeholders all have to come together.
My process goes beyond interface design. I work through discovery and requirements, map workflows and information architecture, design scalable systems, prototype key interactions and collaborate closely with developers through implementation.
The featured project, running in place. It drives itself until you take over.
What I drove, influenced and owned
Four years at the State of Michigan, sixteen in product. The short version of where I moved the needle and where I was the one accountable. The project below is the long version.
- The enterprise design system, from a component library to an atomic model with components, variants and tokens, adopted by multiple cross-platform teams.
- Discovery workshops and requirements sessions with agency leadership and end users, turned into personas, journey maps and implementation roadmaps.
- Modernization planning: legacy dependencies assessed, phased approaches recommended so services stay up while they change.
- Architecture and API integration decisions, made with development and business rather than handed to them.
- Accessibility moved from a final check to a working standard on every component.
- Data-dense internal dashboards and reporting interfaces: complex tables, visualization components and analytics views.
- Usability testing that validated flows before development: card sorting, tree testing, first-click, heuristic analysis.
- The water conditions concept end to end, from a public brief to a live data integration.
The measurements existed. A place to see them did not.
A state water program measures conditions at about 1,200 sites. The public has nowhere to see them together, the staff who review readings before publication work outside the system, and the map still lives in a viewer built a decade ago. The brief asked for one application that serves both audiences, on a data repository the program had already chosen.
- The public and measurement staff need the same numbers, not the same permissions. One codebase with role-gated tools, instead of a public site and a staff tool that drift apart.
- Nothing may look official before staff approve it. Publishing became an event in the design: readings stay provisional and labeled as such until someone signs off.
- The repository was already chosen, so the application should hold no data of record. Every panel maps to an API call, which keeps the data authoritative and the interface replaceable.
- The legacy viewer cannot go dark in one step. The map migrates route by route, each with a way back, instead of a cutover nobody can reverse.
- What I could not know, I wrote down as a question. The open assumptions are the agenda for the first workshops, not a gap buried in a deck.
- 01One surface, two audiences. 1,112 sites on a map, a list you can drive with the keyboard, a detail panel with a year of history, and role-gated tools for staff on the same codebase as the public view.
- 02A working prototype, not a picture. The brief listed 18 deliverables. The prototype came out of it in days, in real HTML with design tokens and both themes, audited to WCAG 2.2 AA.
- 03The reasoning, written for decision makers. Assumptions by confidence, eight decision records with their trade-offs, a system context diagram, and a migration path off the legacy viewer.
- 04Contact with real data. The same prototype now reads a live state data service through a small adapter, and writes back to a sandbox where the review workflow commits an audit trail.
I owned all of it, and it is worth being plain about that: the problem framing, the personas and assumptions, the architecture and its decision records, the design system, the build, the accessibility audit and the live integration. What a team would own in production is written down too, under what this concept does not solve.
The reasoning, written down
Thirteen sections behind the interface: the brief, assumptions sorted by confidence, eight decision records with their trade-offs, a system context diagram, the observation lifecycle, a migration path off the legacy viewer, and an honest list of what this concept does not solve.
Read the case study, opens in a new tab
The UI is real, the integration is designed
My approach is simple: understand the business model first, then design for the user. Whether it's a micro-SaaS bootstrapped by founders or a government platform serving millions, I focus on process, facilitation and measurable outcomes, not just tools. The sentence above is how I present a concept: it tells a product lead what to trust, an engineer where the seams are, and an executive what is still a decision.
I direct the architecture, the design system and every decision. AI accelerates the implementation. The color accessibility validation, the offline fallback strategy, the QC rule design: those are decisions, and they are mine.
On being asked "how long did it take, and did you use AI?"Where does a project start?
With the brief read like a contract. Requirements become a checklist, out of scope becomes a fence, and every screen has to answer a line in that list. Then discovery workshops with the people who will live with the product.
Why build the prototype in the real medium?
Because a working thing gets honest feedback and a picture gets polite feedback. Iterations are cheap, so the open questions get answered by trying, and accessibility is designed in from the first day instead of checked at the end.
How do you keep executives in the loop?
Decision records: the option taken, the options rejected and the trade-off, in one page each. Assumptions sorted by confidence. A migration path instead of a big bang. Leadership can push back on the right thing.
How do you modernize a legacy system?
Route by route. The new interface fronts one workflow at a time behind a shared entry point while the legacy app keeps serving what has not migrated, with a way back for each route. Nobody does a big-bang cutover on a system people depend on.
Why one codebase for public and internal users?
Role-gated affordances over duplicated apps. Same views, identity claims decide what renders. It halves the maintenance surface and keeps the public and staff looking at the same truth.
What is usually the hardest part?
Getting the domain right. Dashboards fail when the domain is wrong, not when the CSS is. So I learn the units, the datums and the rules before I draw a card, and I say plainly what a concept does not solve yet.
Sixteen years designing products people work in
Senior product designer with 16 years of experience leading end-to-end UX, enterprise design systems and technology modernization. At the State of Michigan I structured the enterprise design system and facilitated collaboration between design, development and business stakeholders. My focus is process, facilitation, stakeholder alignment and measurable outcomes, not just tools.
Senior product designer
- Led the evolution of the enterprise design system to an atomic model in Figma (components, variants, tokens), adopted by multiple teams across desktop, tablet and mobile.
- Architected data-dense internal dashboards and reporting interfaces: complex tables, visualization components and analytics views.
- Facilitated discovery workshops and requirements sessions with agency leadership and end users; defined personas, journey maps and implementation roadmaps.
- Designed WCAG 2.1 AA components and worked with development teams through specs and documentation to land them accurately.
- Integrated AI tools (Claude, Gemini, v0, Lovable) into exploration and rapid prototyping while keeping strategic ownership of the design.
Senior UX/UI designer
- Facilitated roadmap sessions with cross-functional stakeholders; wireframes and prototypes under the Human Interface Guidelines; design system on atomic principles, in direct collaboration with the developer team.
Senior UX/UI designer
- Figma wireframes and prototypes, an atomic design system on Material Design, user research and usability testing with UserTesting, accessibility testing.
Senior UX/UI designer
- Proof-of-concept wireframes, mockups and prototypes in Adobe XD; research, design system contributions and QA support.
Head of digital editorial
- Led designers, developers and content creators; defined design standards and style guides; personas and interaction flows.
Lead UX/UI designer
- Managed visual designers and developers on client projects; user studies, UI/UX assets and branding; design QA in Agile delivery.
Webmaster and web designer
Design and research
AI-accelerated design
Accessibility and delivery
Data, maps and cloud
Education
- Master's, Corporate Communication Management
- Universitat de Barcelona, 2014 to 2015
- Bachelor's, Digital Graphic Design
- Universidad Regiomontana, 2004 to 2007
- Inbound Marketing Certification
- HubSpot Academy, 2019