I am Eldrin BernardinoI'm a UI/UX DesignerUI/UX Designer
Start toship.
I design the whole thing, from the first question to the last QA pass.
I'm a UI/UX designer based in Quezon City, with four years of building websites and apps for teams in the Philippines, Australia, Germany and the US. Right now I'm a Senior UI/UX Designer and Assistant Creative Director at Praxxys Solutions.
Most of my work starts before the screens: sitting with clients, working out what the product really needs, then carrying it through design, handover and QA. I studied Information Systems, so I'm at home talking with developers, and these days AI tools are part of how I work, to move faster without cutting corners.
More about me →WorkDesign SystemMost design system case studies come from product companies: one brand, one product, a dedicated team. My situation is different. I work at an agency, and in any given quarter we might be designing for a university, a hotel group, a restaurant chain and a logistics company, each with its own brand and timeline. This piece covers how I approach a design system in that setting, where the goal isn't one perfect brand system but a shared foundation that every project can start from. Before we had a shared system, every project started from a blank file, or from a copy of the last project with someone else's colours still in it. Designers rebuilt the same buttons, form fields and cards over and over. Developers received files where the same grey had five slightly different values. Handover meetings turned into long conversations about which spacing was "right." None of this was anyone's fault. It's what happens when a small team moves fast across many clients. But it meant we were spending time on the parts that should be solved once, instead of on the parts that make each project different. Nielsen Norman Group describes this payoff well: with a design system, designers spend less time on basic visuals and more on complex problems like workflows, and shared terminology cuts miscommunication across teams. Figma's data science team ran a controlled study where designers with access to a design system finished a task 34% faster than without one. Figma notes that the system in the study was up to date and directly relevant, so they treat 34% as an upper bound. Still, it matched what I was seeing. NN/g also gives the honest warning: building and maintaining a system takes time and a dedicated team, and the payoff comes later. A custom system costs more as you customise it. For an agency, that raises a real question. How do you build one system when every client looks different? My answer was to separate what changes between clients from what doesn't. What changes: colour, typography, corner radius, imagery, tone of voice. What stays the same: how a form field behaves, its states, its spacing logic, accessibility rules, how a modal or a navigation drawer works. If the second list is solid, the first list is just a theme. The system is built on design tokens, named values for colour, type, spacing, radius and elevation, set up in layers. Primitives. The raw palette and scales: blue-500, space-4, radius-md. These change completely per client. Semantic tokens. Named by role, not appearance: color-background, color-text-muted, color-action-primary, color-border-subtle. Components only use these. Component tokens, used sparingly, for the few cases where one component needs its own value. This mirrors how IBM's Carbon system organises colour. Carbon names tokens by the UI element and role they apply to, uses suffixes like -hover, -active and -disabled for states, and says component tokens should never be used outside their own component. I borrowed that discipline directly. A button should never know it's blue. It should only know it's the primary action. In Figma, I set this up with variables and modes. Primitives live in one collection; semantic tokens point to them. Switching a project to a new client means remapping the semantic layer to a new palette, not touching a single component. Light and dark mode work the same way: a dark theme is another mode on the semantic layer, which is how I approached a website with dark mode for a content services client. A token is only useful if developers use the same name. So I align token names with the front-end team before anything goes into Figma, and we keep one naming convention across design files and CSS variables. The standard for this has caught up. In October 2025, the W3C Design Tokens Community Group released the first stable version of its specification (2025.10). It defines a vendor-neutral format for sharing design decisions between tools, with support for aliases, light and dark modes, brand themes and modern colour spaces. Tools like Style Dictionary, Tokens Studio and Terrazzo serve as reference implementations, and Figma, Penpot, Sketch and others support it or are working on it. For an agency, a shared format means our tokens don't have to be locked to one tool or one client's stack. On top of tokens sit the components. I kept the first version deliberately small: Buttons, links and icon buttons Form fields, selects, checkboxes, radios and validation states Cards, lists and tables Navigation: header, footer, mobile menu, tabs, breadcrumbs Feedback: alerts, toasts, modals, empty and loading states Every component has all its states designed (default, hover, focus, active, disabled, error, loading) because missing states are where handover questions come from. Focus states and contrast are checked at the token level, so a new client palette that fails contrast shows up before it reaches a screen. Documentation is short and practical: when to use a component, when not to, and a do/don't pair. NN/g lists guidelines as a core part of a design system, both to onboard new people and to remind experienced ones. As the person who mentors our junior designers, I've found this is where the system pays off fastest. New team members learn our standards by using them. I also use AI tools in maintaining the system. I've built custom Claude Skills for design system work, which help me draft component documentation, check naming consistency and turn a token set into a starting front-end theme. It doesn't replace design judgement, but it takes care of the repetitive parts of keeping docs and tokens in sync, which is usually the first thing that falls behind on a busy team. Flexibility vs. consistency. Some clients need something the system doesn't have. I allow project-level components, but if the same need shows up twice, it gets promoted into the shared system. Speed vs. distinctiveness. A shared base risks making every project look the same. Tokens handle the surface, but layout, imagery and art direction still have to be done fresh for each brand. The system speeds up the parts that should be the same, not the whole design. Maintenance is real work. A system that isn't updated drifts from the code within months. It needs an owner and a regular review, not just a launch. Adopt the DTCG format end to end, so tokens go from Figma to code through a pipeline instead of by hand. Add usage tracking, so we can see which components get used, detached or overridden, and fix the ones that keep getting worked around. Grow the pattern library beyond components: page templates for common project types like booking flows, listing pages and dashboards. For an agency, a design system isn't about making every project look alike. It's about solving the same problems once, so the team has more time for what makes each client different. Nielsen Norman Group, Design Systems 101: https://www.nngroup.com/articles/design-systems-101/ Figma, Measuring the value of design systems: https://www.figma.com/blog/measuring-the-value-of-design-systems/ IBM Carbon Design System, Color tokens: https://carbondesignsystem.com/elements/color/tokens/ W3C Design Tokens Community Group, Design Tokens specification reaches first stable version: https://www.w3.org/community/design-tokens/2025/10/28/design-tokens-specification-reaches-first-stable-version/ Design Tokens Community Group: https://www.designtokens.org/
CraftUX ResearchAt an agency, research rarely looks like it does in textbooks. There's no dedicated research team, the timeline was agreed before anyone asked what users need, and the budget is usually tight. But skipping research doesn't save time. It just moves the cost to the end of the project, when a client sees the build and says "this isn't how our customers work." So I treat research as something that has to fit the project, not something to skip. Here's how I approach it. The most common mistake I see is picking a method first. "Let's do a survey" before anyone has said what we're trying to learn. Nielsen Norman Group has a useful framework for this. They map methods along three dimensions: Attitudinal vs. behavioral: what people say versus what people do. Qualitative vs. quantitative: qualitative methods are better for "why" and "how to fix" questions, quantitative for "how many" and "how much." Context of use: whether people use the product naturally, follow a script, see a limited version, or don't use it at all. They also tie methods to project stages. Early, to find direction: interviews, field studies, diary studies, surveys, concept testing. During design, to improve it: card sorting, tree testing, usability testing. After launch, to measure it: benchmarking, analytics, A/B tests, surveys. That's how I plan. I write down the two or three questions we need answered, figure out the stage we're in, and the method usually picks itself. On almost every project, research starts with the client. Requirement gathering with stakeholders and our system analysts tells me the business goals, the constraints and who the users are supposed to be. It also tells me the assumptions. A university team might be sure students care most about program listings. A bank might assume customers want more features in the app. Those assumptions are what I want to test with real users. When I can get access to users, interviews are my main tool. NN/g's guidance shaped how I run them: Ask about specific past events. "Tell me about the last time you booked a hotel room" beats "How do you usually book hotels?" The second gets you an idealized version. Ask for extremes. Particularly frustrating or particularly smooth experiences are vivid, so people remember details. Don't lead. People will form an opinion about almost anything when asked. Pushing for answers creates opinions they didn't really have. Don't ask them to design. Interviews are bad for specific UI decisions, like menu types or button colors, and for predicting whether people would use a feature that doesn't exist yet. Listen to what users say about their lives. Watch what they do with the design. Don't confuse the two. For mobile apps with more than one kind of user, like a logistics app with customers and drivers, I talk to both groups separately. Their goals and context are completely different, and one group's needs can't stand in for the other's. Surveys are tempting because they're cheap and give you numbers. They're also easy to get wrong. A few rules I follow: Use them for "how many", not "why." Interviews explain. Surveys measure. Keep them short. Every extra question lowers completion and quality. Ask about behavior and facts where possible, not hypothetical preferences. Pilot with two or three people before sending it out. Confusing questions show up immediately. Usability testing is where research turns directly into design changes. NN/g's well-known guidance is that five users in a qualitative test find most of the usability problems you'd find with many more, and that the return drops quickly after that. The important part of that advice is often skipped: it assumes you test, fix and test again. Several small rounds beat one big one. And if you have distinct user groups, each one needs its own participants. For quantitative studies with statistics, you need far more people, at least 20 according to NN/g. On agency timelines, my version is simple: a few people, a clickable Figma prototype, three to five realistic tasks, and a quick round of fixes before the next review. Raw notes don't change a design. Synthesis does. My go-to is affinity diagramming, usually in FigJam: Everyone writes notes alone first. One observation or quote per sticky. Working alone first reduces groupthink. Cluster by content. Group related notes, then label each group with a clear theme. Don't throw away small clusters. Outliers can be the most interesting finding. Decide what to do. For each theme: design change, open question, more research, or no action. Each gets an owner. NN/g makes the point that the conversation while clustering matters more than the final diagram. That matches my experience, especially with developers in the room. This is the step that gets lost most often. A research deck full of insights that nobody acts on is wasted effort. So I connect each finding to something concrete: A user journey document that shows where problems happen. Design principles for the project, written from the findings. Specific screen changes, with the finding noted in the Figma file next to the design. When a client pushes back on a decision, being able to point to what users actually did is far more convincing than my opinion. I've built Claude Skills for UX research and user journey documents. They help me draft interview guides, spot leading questions, summarize transcripts and turn clustered notes into a first draft of findings. That saves real time on agency schedules. I still review everything against the source notes, because a summary that sounds right but misquotes a user is worse than no summary. Running research after the design is already approved. Treating stakeholder opinions as user research. Recruiting only friendly or internal users. Reporting findings without recommendations. Testing once and calling it validated. Nielsen Norman Group, "When to Use Which User-Experience Research Methods": https://www.nngroup.com/articles/which-ux-research-methods/ Nielsen Norman Group, "Interviewing Users": https://www.nngroup.com/articles/interviewing-users/ Nielsen Norman Group, "How Many Test Users in a Usability Study?": https://www.nngroup.com/articles/how-many-test-users/ Nielsen Norman Group, "Affinity Diagramming": https://www.nngroup.com/articles/affinity-diagram/
WorkPinoy E-commerce NowadaysMost e-commerce playbooks are written for a shopper who sits at a laptop, pays by credit card and never talks to anyone. That shopper exists here, but they aren't the majority. Over the last four years I've designed storefronts and shopping apps for retail and lifestyle brands in the Philippines, including a fashion retailer's website and customer mobile app. The biggest lesson from that work is simple. If you design for the Filipino shopper you imagine, you'll miss the one who actually shows up. This piece covers what I've learned about that gap and how it changes the design. The numbers explain a lot. The latest e-Conomy SEA report from Google, Temasek and Bain puts the Philippine digital economy at about $36 billion in gross merchandise value for 2025, up 16% year on year, with e-commerce as the largest slice. Video commerce grew 35% on its own (BitPinas). Reach is just as big. DataReportal counted 97.5 million internet users in the Philippines in January 2025 and 90.8 million social media user identities, about 78% of the population (DataReportal). Most of those people meet a brand first in a feed, on a phone, between other things. So the starting point for every retail project I take on is the same. It's a phone, a mid-range one, on mobile data that isn't always fast. The customer probably found you through a post or a live selling video, not a search. Off-the-shelf storefront themes are good at the basics. Where they struggle is with three local habits. Cash on delivery is still a real payment method. Xendit's Ecommerce Payments Momentum Report 2026 found that cash on delivery still makes up 23% of Philippine e-commerce transaction value on its platform, the highest of the six Southeast Asian markets it studied. Even more telling, 41% of Filipino shoppers who abandoned a purchase in the previous three months said their preferred payment method wasn't available (Daily Tribune). People want to ask before they buy. "Available pa po?" is practically a national checkout step. Shoppers message the page to check sizes, stock, delivery areas and whether the photo matches the item. Surprise costs kill the sale. This one is universal, but it hurts more when the budget is tight. Baymard's research puts the average documented cart abandonment rate at 70.22%. Among shoppers who abandon for reasons other than "just browsing", 40% blame extra costs like shipping and fees, and 12% say they couldn't see or work out the total up front (Baymard Institute). A Filipino shopper's checkout doesn't start at the cart. It starts in the chat window, and it ends when the rider hands over the parcel. I treat the whole journey as the product: discovery, the chat, the cart, the payment and the delivery. Here are the decisions I keep coming back to. "Mobile first" usually means the desktop layout squeezed down. I design the phone layout first and treat desktop as the expansion. Product cards are built for thumbs: big tap targets, the price in bold, and the main action within reach of the thumb. Images are cropped for portrait screens because that's where traffic comes from, especially from social links. Pages are kept light. Fewer heavy carousels, compressed images, and skeleton states so slow connections still feel responsive. I put payment methods on the product page, not just at checkout. A small row saying COD, GCash, cards and bank transfer near the price answers the question before it turns into a reason to leave. For cash on delivery, the design job is to set expectations: Show clearly whether COD is available for the shopper's area. Remind them to prepare the exact amount, and show it in big, plain numbers on the confirmation screen. Keep order tracking simple so the shopper knows when to expect the rider. On the business side, COD carries risk, so I'll often design light friction for first-time COD orders, such as a confirmation message, rather than removing the option entirely. Rather than fighting the urge to chat, I design for it. On the fashion app and site, that meant: A "Message us about this item" entry point on the product page that carries the product name, size and photo into the conversation, so the shopper doesn't have to describe it. Clear size guides and real-person photos to answer the most common questions before anyone types them. A visible store schedule for chat replies so silence doesn't read as "no stock." Given how often unexpected costs cause abandonment, I push for an estimated delivery fee as early as the product page, plus a running total in the cart that already includes shipping once a location is set. Vouchers and promos sit right next to the total so shoppers can see the effect immediately. Not everything is a win. COD versus operations. Cash on delivery lifts reach but adds failed deliveries and reconciliation work. Design can ease this, but it's a business decision, and I present it to the client that way. Chat versus self-service. Every chat button adds load for a small support team. The goal is to make the page answer most questions so the chat handles only the real edge cases. Speed versus brand richness. Fashion clients love big visuals and motion. On a slow connection, those can stop the page from loading. We usually agreed on one hero moment per page and kept everything else lean. I can't share client numbers, but the pattern held. Once payment options and delivery fees were visible early, the team got fewer "how much is shipping?" messages and fewer carts left at the delivery step. The app also gave repeat buyers a faster path. Saved addresses and a preferred payment method made reordering a few taps instead of a full checkout. Design for video commerce. With video commerce growing fast, I'd want short product clips and live-selling replays on the product page itself, linked straight to the size and add-to-cart controls. Test with real devices on real data. I'd set up regular usability sessions on mid-range Android phones over mobile data, not office Wi-Fi. Make COD smarter. Use order history to offer COD confidently to trusted repeat customers while gently nudging new ones toward QR Ph or e-wallets. Use Taglish where it fits. Microcopy that sounds like the brand's chat replies feels more honest than stiff formal English, as long as it stays clear. Filipino e-commerce isn't behind. It's different. Design for the phone, the chat and the cash, and the shop stops feeling like a foreign template. BitPinas, "PH Digital Economy Posts 16% Increase" (e-Conomy SEA 2025 coverage): https://bitpinas.com/fintech/ph-digital-economy-2025/ DataReportal, "Digital 2025: The Philippines": https://datareportal.com/reports/digital-2025-philippines Daily Tribune, "Cash on delivery still dominates PHL online shopping" (Xendit Ecommerce Payments Momentum Report 2026): https://tribune.net.ph/2026/10/20/cash-on-delivery-still-dominates-phl-online-shopping Baymard Institute, "Cart Abandonment Rate Statistics": https://baymard.com/lists/cart-abandonment-rate
OpinionAI Is the Worst Thing That Happened to Creatives... Or Is It?Every few weeks someone in a design group chat posts a screenshot of a generated landing page with the caption "it's over." And every few weeks I open Figma, Claude, ChatGPT and Gemini and keep working, because the job isn't over. It moved. So here's my take, up front: AI is the worst thing that ever happened to one kind of creative work, and one of the best things to happen to the rest. The kind it hurts is production done without judgment: resizing, filler copy, stock-looking visuals, the forty-variant banner set. The kind it helps is everything that needs taste, context and someone willing to put their name on a decision. That isn't a vibe. Let's look at the receipts. The "should creatives use AI?" debate is mostly settled by behaviour, not argument. Adobe's first Creators' Toolkit Report (Harris Poll, 16,000+ creators across eight countries, September 2025) found 86% of creators actively using creative generative AI, and 76% saying it helped grow their business or following. The top uses weren't "make me a masterpiece." They were editing, upscaling and enhancement (55%), generating new assets (52%) and ideation (48%). Figma's 2025 AI report, which surveyed 2,500 of its users, found 78% agree AI significantly boosts their efficiency. That matches how I actually work. AI is in my brainstorming, my first drafts of UX copy, my documentation, my research summaries, and the Claude Skills I build so the boring parts of a workflow run the same way every time. It's the most useful tool I've picked up in four years. Here's the number that should get more attention than any adoption stat. In that same Figma report, only 32% of respondents said they can rely on AI's output. Designers were also noticeably less impressed than developers: 69% of designers reported being satisfied with AI tools versus 82% of developers, and only 54% of designers said it improves the quality of their work. Fast is not the same as good, and the gap between them is exactly where a designer earns their pay. That gap is the whole story. AI gets you to something very quickly. It doesn't know that the client's users are mostly on old Android phones, that the legal team will reject that headline, or that the "clean" layout it produced breaks the design system in three places. Somebody has to know that. That somebody is the job now. Adobe's numbers say the same thing from the other side. Creators' top barriers were cost (38%), unreliable output quality (34%) and not knowing how the model was trained (28%). The tools are popular and still untrustworthy, both at once. I don't want to wave the fear away, because some of it is earned. Jobs are shifting, and not evenly. The World Economic Forum's Future of Jobs Report 2025, built from a survey of 1,000 employers covering 14 million+ workers, put graphic designers as the 11th fastest-declining job category, a role it had called "moderately growing" in its previous edition. If your work is mostly turning a brief into assets, that's a real threat, not a hot take. Consent is a real grievance. Adobe found 69% of creators worry their work will be used to train AI without permission. That isn't paranoia. It's a fair reaction to an industry that scraped first and asked later. The legal ground is shaky for pure output. The U.S. Copyright Office's January 2025 report on copyrightability concluded that prompts alone don't make you the author of what comes out. Protection needs a human who determined enough of the expressive elements. In March 2025 the D.C. Circuit agreed in Thaler v. Perlmutter that a work made autonomously by AI can't be registered, and the Supreme Court declined to hear the appeal in March 2026. So if your plan is "prompt it, ship it, own it," the law is not on your side. Read those same receipts again and a different picture shows up. That WEF report that made designers panic? The same coverage notes it ranked UI and UX design as the eighth fastest-growing job category. Demand didn't vanish. It moved toward people who design systems, flows and decisions instead of single artefacts. The copyright rulings cut the same way. The Copyright Office explicitly said that using AI to assist the creative process doesn't block copyright, and that human selection, arrangement and modification can be protected. The D.C. Circuit said the human-authorship rule still rewards people who make work with the help of AI. The law isn't punishing creatives who use AI. It's punishing the absence of a creative. And look at what creators actually use it for in Adobe's data: editing, enhancing, brainstorming. The people using these tools the most aren't asking to be replaced. They're asking for leverage. No made-up productivity percentages here, just the honest shape of it: Blank pages are gone. I rarely start from nothing. I start from three rough directions and spend my energy choosing and fixing. Documentation stopped being the thing nobody does. Handover notes, component specs and QA checklists get drafted by AI and corrected by me. Judgment got more expensive. When anyone can generate ten options, the scarce skill is knowing which one is right for this user and this brief, and explaining why to a client. Junior work changed. Mentoring now includes teaching people to distrust a confident output, not just how to use auto layout. AI is the worst thing that happened to creatives who were only ever paid for output. For everyone else it's a strong, flawed assistant that makes taste, context and accountability worth more, not less. If you want a practical checklist, this is mine: Use it for the first 60%, own the last 40%. Generation is cheap. Editing, rejecting and refining is where you add value. Keep a human hand you can point to. Selection, arrangement, modification: that's where your craft and your copyright live. Know your tool's training story. If a client asks where a visual came from, "the AI made it" isn't an answer. Never ship unread output. Only 32% of builders say they can rely on it. Act like it. Move up the stack. Systems, research, flows and client conversations are where the growth is. Production alone is where the decline is. Build your own workflows. Prompts you reuse, skills you write, checklists you trust. The advantage isn't having AI. Everyone has it. It's having a process. So, worst thing ever? Only if you let it make the decisions. Adobe, Creators' Toolkit Report (MAX 2025): https://news.adobe.com/news/2025/10/adobe-max-2025-creators-survey Figma, 2025 AI Report perspectives: https://www.figma.com/blog/figma-2025-ai-report-perspectives/ Creative Boom on the WEF Future of Jobs Report 2025: https://creativeboom.com/news/its-official-ai-is-coming-for-your-graphic-design-job U.S. Copyright Office, Part 2 report announcement: https://www.copyright.gov/newsnet/2025/1060.html U.S. Copyright Office, Copyright and AI hub: https://www.copyright.gov/ai/ Skadden on Thaler v. Perlmutter (D.C. Cir., March 2025): https://www.skadden.com/insights/publications/2025/03/appellate-court-affirms-human-authorship Baker Donelson on the Supreme Court denying certiorari: https://www.bakerdonelson.com/supreme-court-denies-certiorari-in-thaler-v-perlmutter-ai-cannot-be-an-author-under-the-copyright-act
View more case studies →From wireframe to working product.
Every chapter, a new craft.
2015 — 2019
BS Information System
La Verdad Christian College
Studied web and iOS app development, software engineering, project management and e-commerce.
- Web apps
- Software engineering
- Project management
2020 — 2021
Graphic Designer
Aether Design
Freelance graphic design and video editing for a creative studio in Caloocan City.
- Photoshop
- Premiere Pro
- CorelDRAW
2021 — 2022
Video Editor
Mess Energy
Freelance video editing and graphics for an energy company in Singapore.
- Premiere Pro
- After Effects
- Photoshop
2022 — Present
Senior UI/UX Designer
Praxxys Solutions
Assistant Creative Director. I lead design end to end, from requirements to dev handover and QA, for clients in education, finance, hospitality, F&B and more.
- Figma
- Design systems
- Agentic AI
The tools behind the work.
Figma
Interface & design systems
Daily
Photoshop
Image editing
Comfortable
Premiere Pro
Video editing
Comfortable
After Effects
Motion
Comfortable
Blender
3D design
Familiar
Google Workspace
Docs & collaboration
Daily
Claude
Agentic design & build
Daily · AI
ChatGPT
Ideation & writing
Comfortable · AI
Gemini
Research & ideation
Familiar · AI
And a little code.
- HTML & CSS Comfortable
- JavaScript Familiar
- Vue & Nuxt Familiar
- Three.js & WebGL Familiar
- Git & GitHub Familiar
How I work.
Four steps, every project. The line fills in as you scroll.
Briefing
Goals, users, constraints and what success looks like, written down before any pixels.
- Brief doc
- Success metrics
- Constraints
Mind mapping
Everything the product could be on one page, then cut down to what it should be.
- Feature map
- Scope cut
- Priorities
UX research
Talk to users, study the market, and let evidence settle the arguments.
- Interviews
- Survey
- Competitor scan
User journey
Follow a person from first click to goal and fix every place they stall.
- Journey map
- Pain points
- Wireframes