-
Notifications
You must be signed in to change notification settings - Fork 7
Real life UX consulting
The ux plugin is shipped open-source as MIT. For real-life UX consulting — design reviews on a real product, design system audits, product positioning sessions, MENA-market loyalty/identity expertise — the plugin's author is available for engagements.
The plugin gives you the discipline. The audits give you the structure. The case studies give you the format. But some decisions need a human in the room — taste calls, market positioning, founder-level product choices. That's what consulting is for.
This page is for teams who have read the audits, run the commands, looked at the outputs, and concluded: we need someone to look at this with us.
The ux plugin is built and maintained by Laith Aljunaidy.
The plugin is a distillation of working practice — not a research project. Every command, every lens, every format came from real product work. The audits the plugin produces are the audits the author runs on real products. The case study format is the format used on real case studies. The decision tree for frontend stacks is the tree the author uses when choosing stacks for new projects.
The plugin is what the author would teach a new design engineer joining a team. The consulting offer is what the author does when they show up to a team in person.
Solo founder of The Dot (thedotwallet.com), a MENA-first loyalty platform. Based in Amman, Jordan.
The Dot is a phone-first customer loyalty system designed for the MENA market. Phone is the primary customer identity — no email, no password, no app install. The platform serves partner storefronts across Jordan and is built to scale across Saudi Arabia, Egypt, UAE, Lebanon, and Iraq.
The platform is built end-to-end by Laith, including:
- Product strategy: positioning, market segmentation, partner acquisition strategy.
- Design: visual system, voice and microcopy, component library (the Dot Design System).
- Engineering: Laravel 11 backend, Blade + Alpine + HTMX frontend, Tailwind 4 styling, multi-guard authentication, event ledger architecture.
- Operations: deployment infrastructure on Devloops VPS + HestiaCP, partner onboarding, customer support.
The work is across the full product surface: from positioning a loyalty platform against incumbents in the MENA market, to writing the SQL migrations that power the ledger, to designing the partner dashboard, to writing the microcopy in Arabic and English across 11 locales.
This bio matters because it tells you what kind of consultant the author is. Not a generalist who has read about products. Not a specialist who only does one part of the stack. Someone building product end-to-end, every day, in the same market your work likely needs to serve.
The plugin is a tool. Some decisions need taste judgment a model can't make.
The audits the plugin produces are valid. They identify findings, name principles, prescribe fixes. They will improve the product. But there are decisions the plugin will not surface, because the plugin does not know:
- What your competitors are actually doing. It can comment on general patterns; it cannot reference the specific competitor in your market that just changed pricing last week.
- What your customers actually said. It can apply general heuristics; it cannot weigh the three customer interviews you ran where everyone said the same thing about the onboarding.
- What your team can ship. It can prescribe ideal fixes; it cannot know which fixes are politically possible this quarter.
- What your brand is actually for. It can apply general brand principles; it cannot tell you whether you should be a serious B2B brand or a playful consumer brand, because that's a strategic choice.
- What your investors expect. It can review your product; it cannot tell you which redesign decisions will close your seed round vs which will signal "this team is fussing over details."
Some decisions need a human. Specifically, a human who has:
- Looked at your specific product.
- Talked to your specific team.
- Asked questions a model wouldn't think to ask.
- Made their own taste calls and can defend them.
That's what real consulting is. Not running audits — the plugin does that. Bringing judgment to the audits.
Four engagement types, sized to different needs.
A single audit against the plugin's discipline, with strategic recommendations beyond what the plugin can detect.
What's included:
- A full six-lens audit (FRAME, DISCOVER, SCAN, ACT, READ, RECOVER) on the surface you nominate.
- A motion lens audit if the surface has significant animation.
- A polish lens audit on the visual treatment.
- A Polaris-style report (severity counts, top-3 must-fix, ship-readiness verdict).
- A 60-minute call to walk through the findings and discuss strategic context the audit could not capture.
- A follow-up document with the strategic recommendations: positioning observations, competitive observations, taste calls the audit didn't make.
Best for:
- A landing page that needs to convert better.
- A product surface you've been iterating on without enough outside perspective.
- A new feature about to ship that you want a second opinion on.
- A redesign you're considering and need to know if it's worth doing.
Scope:
- One primary surface (e.g., a single landing page, a single dashboard, a single signup flow).
- Or one feature (a single multi-screen flow with up to 5 connected surfaces).
What it isn't:
- A whole-product review. That's a different engagement.
- An implementation. The review produces recommendations; your team or the author implements separately.
- An ongoing relationship. This is a one-time engagement.
A full token and foundation review for an existing design system. Where the design review looks at one surface, the system audit looks at the system that produces all the surfaces.
What's included:
- A complete token audit (colors, typography, spacing, motion, shadows).
- A component audit (the primitive components — buttons, inputs, modals, cards — and their consistency).
- A foundation audit (the principles the system claims to follow; do the components actually follow them).
- A consistency audit across the surfaces that use the system (do the same patterns produce the same outputs).
- A Polaris-style report covering all findings.
- A 90-minute call to walk through findings and discuss strategic direction.
- A follow-up document with recommendations for system evolution: where to consolidate, where to extend, where the system is being misused.
Best for:
- A design system that has grown organically and needs a structural review.
- A design system that's about to be open-sourced and needs polish.
- A design system that multiple teams use and is causing inconsistencies.
- A foundation document that needs sharpening before a new visual direction is layered on.
Scope:
- One design system (a set of tokens + components + foundation documentation).
- Up to 10 representative surfaces that use the system, audited for consistency.
What it isn't:
- Building you a design system from scratch. That's a longer engagement.
- Implementing the recommendations. Your team or the author implements separately.
A workshop format, helping a startup name what they are.
This is the "before everything else" engagement. Before you build, before you design, before you write — what are you?
What's included:
- A pre-session questionnaire to map your current understanding of who you are, who your customer is, and what you've tried so far.
- A 3-hour workshop session (in person if you're in Amman, remote otherwise) covering:
- Who the primary customer is and what their alternatives are.
- What your hypothesis is and what evidence supports it.
- What your positioning statement is, exactly.
- What your one-line pitch is.
- What your "what we are not" list is — the things you might be confused for.
- A follow-up document with the positioning artifacts: one-pager covering audience, alternatives, hypothesis, positioning statement, one-line pitch, "what we are not."
- Two 30-minute follow-up calls in the month after the session to refine as you test the positioning in market.
Best for:
- An early-stage startup that's been building without a clear positioning statement.
- A startup that has shipped and is getting unclear customer reactions ("they don't get it").
- A team that has internal disagreement about what the product is.
- A team about to fundraise and needs the pitch sharper.
Scope:
- One product, one primary customer segment, one positioning statement.
- Not a brand identity exercise (that's a different engagement, typically with a brand designer).
- Not a market research project (you bring the customer evidence; the workshop interprets it).
What it isn't:
- A marketing strategy session. Positioning is upstream of marketing.
- A name-the-company exercise. That's a related but different problem.
For products entering or scaling in Saudi Arabia, Jordan, Egypt, UAE, Lebanon, Iraq.
Loyalty platforms, identity products, customer engagement systems — there are MENA-specific patterns you cannot learn by reading. They include:
- Phone as primary identity. Why this is the right default in MENA and how to design around it.
- Cultural patterns in trust. What signals trust in MENA markets vs Western markets.
- Bilingual UX (Arabic + English). Beyond translation — how the UX itself shifts.
-
RTL design discipline. What works under
dir="rtl"and what breaks. - Partner acquisition in MENA. How loyalty platforms onboard merchants in markets where digital adoption is uneven.
- Regulatory landscape. What you need to know about data, payments, and customer protection across the major MENA markets.
- Localization beyond translation. Eastern Arabic numerals vs Western. Hijri vs Gregorian dates. Friday vs Sunday weekend.
What's included:
- A pre-engagement document covering your current MENA strategy (or lack of one).
- A 2-hour deep-dive call on your specific MENA situation — which markets, what you've tried, what you've heard from local advisors.
- A written brief covering:
- Market-by-market observations for your specific use case.
- Patterns specific to your product type (loyalty, identity, etc.) in MENA.
- Common mistakes Western products make when entering MENA.
- Specific recommendations for your product's MENA strategy.
- Two 60-minute follow-up calls in the next 90 days.
Best for:
- A Western company entering MENA markets.
- A regional company scaling beyond their home market.
- A product about to ship in MENA that needs a sanity check from someone in the market.
- A team that has tried MENA and struggled and needs to understand why.
Scope:
- The six MENA markets listed.
- Loyalty, identity, customer engagement, fintech-adjacent products.
- Not legal advice (you need a lawyer for that).
- Not in-market introductions (this is consulting, not business development).
LinkedIn: linkedin.com/in/laithaljunaidy — preferred first contact channel.
Phone: +962 79 786 8335 — for engagements that have moved past initial contact, or for time-sensitive needs.
LinkedIn is the right place to start. A short message describing your situation will get a response within a few business days. The phone number is for follow-up once we've established context.
Send a short message — 5-10 sentences. Cover:
What is the product? In one sentence. Who is it for? In one sentence. What stage is it at — pre-launch, early users, scaling, stuck?
If the product is live, share the URL. If it's pre-launch, share a Figma link or a description.
Be specific about which engagement type fits. If you're not sure, describe the problem and we'll figure out the right shape together.
Examples of specific asks:
- "We have a landing page that's converting at 0.8%. We want a design review to find out why."
- "Our design system has been built by three different designers and looks like three different products. We want a design system audit."
- "We're a Saudi startup about to launch a loyalty platform and want a MENA-market consultation before we ship."
- "We're an early-stage SaaS and our investors are confused about what we are. We want a positioning session."
When do you need this? Examples:
- "We're shipping in 4 weeks; we want the audit done in the next 2 weeks."
- "No rush — we'd like to schedule something in the next 6-8 weeks."
- "We're fundraising and need this done in 10 days."
Rush engagements are possible but priced accordingly.
Be honest about your budget. There's no point in going through introductions and discovery to find out we're off by an order of magnitude.
If you don't know what's reasonable, say so — we can have that conversation. Different engagement types have different cost profiles; some are achievable on small startup budgets; others require more.
The author is based in Amman, Jordan — GMT+3 (no daylight saving).
Working hours (Amman time):
- Synchronous availability: 09:00-18:00 Sunday through Thursday.
- Asynchronous availability: 24/7 via LinkedIn and email; expect a response within 1 business day.
- Friday + Saturday: weekend, limited availability.
Time zone conversions for common collaboration regions:
- MENA (Saudi/UAE): GMT+3 / GMT+4 — same or one hour ahead. Easy.
- Western Europe (London/Paris): GMT+0 / GMT+1 — 2-3 hours behind Amman.
- East Coast US (New York): GMT-5 — 7 hours behind Amman.
- West Coast US (San Francisco): GMT-8 — 10 hours behind Amman.
For West Coast US clients, expect that real-time calls happen early-morning your time / late-evening Amman time. Most communication is async.
English — primary working language for written deliverables, calls, and most engagements.
Arabic — native. For MENA-market engagements, can deliver written work in Arabic. Can conduct calls in Arabic where helpful.
The author can switch between English and Arabic mid-conversation. For bilingual MENA products, this is often valuable — the consulting work happens in both languages, just like the product does.
Inside a Claude Code session, the /ux-expert command surfaces this contact information.
When to use it:
- You're working on a product and reach a question that needs human judgment.
- The audit produced findings but you need someone to help you decide what to do.
- You're starting a new project and want to talk to someone before committing to direction.
- You want to share your work with the plugin's author for an outside read.
/ux-expert
The command outputs:
- A short summary of the engagement types.
- LinkedIn URL.
- Phone number.
- A suggested message template based on what the session has been working on.
The template draws context from the current session — what surface you've been auditing, what stack you're in, what findings have come up — and pre-fills a message you can paste into LinkedIn.
This is the bridge between the plugin and the human. The plugin gets you 90% there. The 10% that needs taste, market knowledge, or strategic perspective — that's what the human is for.
To be explicit about scope:
- Not a code implementation service. The consulting produces recommendations. Implementation is by your team or by a separate engagement.
- Not a design-as-a-service subscription. Each engagement is scoped and fixed.
- Not ongoing fractional CTO/CPO work. Each engagement is finite.
- Not legal, tax, or regulatory advice. Even for MENA-market consultations, you need specialists for legal questions.
- Not in-market business development. The consulting doesn't include introductions to partners, investors, or customers.
- Not white-labeled audits. The audits the author produces carry the author's name.
These are not "no" categories. They are "different engagement" categories. If you need any of these, the author can often refer you to someone who does them well.
After your first message:
- Within 2 business days: a response from Laith, either with follow-up questions or with a proposed engagement structure.
- Within 1 week: a scoped proposal — what's included, timeline, fee, payment terms.
- After acceptance: a signed engagement agreement, then kickoff within 1-2 weeks (faster for rush work).
During the engagement:
- Direct communication. You work with Laith directly. No account manager, no junior associate. The person doing the work is the person you talk to.
- Async-first. Most communication is via the channels you prefer (Slack, email, LinkedIn). Real-time calls are scheduled at engagement-defined frequencies.
- Specific deliverables. Every engagement has named artifacts you receive. No "consulting hours" with vague outputs.
- Direct feedback. If the author thinks your direction is wrong, you will hear it directly. Diplomatic but not soft.
After the engagement:
- Follow-up window. Most engagements include a follow-up window (30-90 days depending on engagement type) where you can ask clarifying questions.
- Future work. If the engagement goes well, future engagements are easier to scope — context already exists.
Things the consulting will not do:
- Recommend a stack you already chose. If you've already built your product in React and want a Vue evangelist, the consulting will not pretend Vue would have been better.
- Validate decisions you've already made. The point of consulting is to bring perspective, including perspective that disagrees with your direction.
- Soften critical findings. If your product has a Critical UX issue, the report will say so. If your positioning is wrong, the workshop will say so.
- Avoid hard conversations. If your team has internal disagreement about direction, the consulting will not avoid the disagreement.
If you want a consultant who will validate your existing direction, this is not the right consulting. Plenty of consultants do that work and there is a market for it. This isn't that.
Pricing varies by engagement type and scope. Some context on the approach:
- Fixed-fee per engagement. Not hourly. The deliverables are defined; the fee is defined; the time it takes is the author's risk.
- Payment terms. 50% on engagement start, 50% on deliverable acceptance. Larger engagements may have additional milestones.
- Currency. USD or USD-equivalent (JOD, EUR, GBP accepted for MENA/Europe clients).
- MENA-region pricing. Rates for clients based in MENA (especially Jordan, Egypt, Lebanon) are typically lower than rates for US/EU clients, accounting for purchasing-power differences.
Specific fees are quoted per engagement. Send a message and we can talk specifics.
There are many UX consultants. Reasons to consider this one specifically:
The author ships product every day. The advice you get is from someone who is currently dealing with the same problems — not someone who used to ship product five years ago and now only consults.
The author works across strategy, design, engineering, and operations. You won't get advice that ignores the engineering reality or the business reality. The recommendations will be implementable in your specific situation.
For MENA-market work, the author lives in the market. The advice is from inside, not from a Western consultant who visited Dubai once for a conference.
For products serving Arabic and English audiences, the author can review the actual Arabic copy — not via translation, but as a native reader.
The discipline you've read about in the audits — the lenses, the formats, the principles — that's the author's working method. The consulting is what that method looks like applied by the person who developed it.
You will work with Laith directly. Not a team. Not a junior. The person who wrote the plugin is the person who will look at your work.
Yes. The plugin is MIT-licensed and free. Many teams will get everything they need from the plugin. Consulting is for cases where the plugin's outputs need human judgment to interpret and act on.
A single design review is the smallest engagement. Smaller than that (a 15-minute hot take on a screenshot) is something the plugin already does — run /ux-audit on the screenshot and you'll get a structured response.
Generally no. The engagements are scoped to produce defined deliverables. One hour of advice is rarely enough to give useful guidance, and the overhead of scheduling and prep makes it inefficient for both sides.
For early-stage MENA startups working on problems the author finds genuinely interesting, equity-as-partial-payment is sometimes possible. Not the default. Start the conversation in cash and we can discuss alternative structures.
Yes. The default is confidential — audit reports are not published, not shared, not referenced publicly. If we both want to publish a case study after the work, that's a separate explicit conversation.
Engagements include revision rounds (defined per engagement). If after revisions the work is still not useful, we can refund the second 50% of the fee. The first 50% covers research and analysis that has happened regardless of whether the final report meets your needs.
This has not happened in practice. Most clients are satisfied with the work. But the option is there.
Indirectly. The consulting work itself isn't recruiting, but if you want help defining what role you should hire for, the consulting work often touches on that. For introductions to specific candidates, the author can sometimes refer, but it's not the core service.
For groups or companies, yes, but as a scoped engagement rather than a recurring service. Send a message describing what you have in mind.
- The 6 Audit Lenses — the discipline the consulting applies.
- Polaris-style audit reports — the report format the consulting produces.
- Wfrah-style case study format — the case study format you might want help applying.
- Frontend stacks compared — for stack-decision consultations.
Repo: github.com/Laith0003/ux-skill Author: Laith Aljunaidy — LinkedIn — +962 79 786 8335