Retalik / Original product presentation
01 / Retalik
The problem
- High learning curve for developers.
- Limited theme-creation options.
- Inefficient SEO performance.
Reading the problem / Retalik
Merchant control and customer choice are different tasks.
The SaaS work connects merchant operations, theme configuration and reusable interface foundations.
Theme creation, reusable UI and developer implementation need shared conventions rather than one-off screen decisions.
How can merchants and developers understand the same commerce product from different starting points?
Evidence: the project account and the attributed artifacts on this page. Process drawings and interaction studies are reconstructed explanations; numerical research or business results are included only where separately supported.
02 / Retalik
My role
- Researched e-commerce pain points.
- Designed a minimalist, friendly platform.
- Established a Tailwind-based design system.
03 / Retalik
The process
- Studied merchant and developer workflows.
- Designed the platform and its system.
The process / Retalik
A direction.
A way to build it.
Retalik’s process sits between a merchant configuring a store and a developer maintaining its reusable foundation.
A schematic of sequence and overlap, not a dated project schedule.
Compare merchant and developer needs
Study where store setup, theme work and implementation require different kinds of explanation.
Structure the commerce workspace
Connect settings and content to the storefront behavior they influence.
Explore configuration in context
Use the reconstructed flow study to show how workspace, theme choices and preview relate.
Define the system reference
Connect the product-design contribution to the reusable Tailwind interface foundation.
How can merchants and developers understand the same commerce product from different starting points?
A merchant configures a store; a developer works with the structures that make that configuration possible. Retalik’s design problem sits between those perspectives. The preview becomes the meeting point where a configuration can be judged as a storefront rather than an abstract set of settings.
Journey map / Retalik
See the whole task in context.
Choose a step to connect the person’s intent with the interface and the design decision.
Current intent
Set up the store
Theme creation, reusable UI and developer implementation need shared conventions rather than one-off screen decisions.
- Interface context
- Store workspace
- Review question
- Which settings belong in merchant-facing controls and which belong in developer documentation?
Representative task sequence and recovery path, not a measured emotional curve or historical research map.
Behind the experience
The visible task depends on work behind it.
For Retalik, this map connects “Set up the store” to “Preview the storefront”. Read across to follow the task, then select a layer to inspect the interface, design and delivery references behind it.
| Layer | Set up the store | Choose a theme | Configure content | Preview the storefront |
|---|---|---|---|---|
| The task | Set up the store | Choose a theme | Configure content | Preview the storefront |
| Visible interface | Store workspace | Store workspace | Theme configuration | Storefront preview |
| Design checkpoint | Theme creation, reusable UI and developer implementation need shared conventions rather than one-off screen decisions. | Orient the merchant inside the store workspace. | Group configuration around the storefront behavior it changes. | Let the merchant judge the visible result before release. |
| Implementation reference | Study where store setup, theme work and implementation require different kinds of explanation. | Connect settings and content to the storefront behavior they influence. | Use the reconstructed flow study to show how workspace, theme choices and preview relate. | Connect the product-design contribution to the reusable Tailwind interface foundation. |
| Recovery | Incomplete configuration → identify the missing requirement → return to editing | |||
A reconstructed delivery map: the implementation row summarizes design-process dependencies, rather than claiming to document the original backend architecture.
Role-specific views on shared foundations.
Reconstructed comparison of design approaches. These are review studies, not a claim that both directions were historically tested or shipped.
What this direction changes
Role-specific views on shared foundations
Allows distinct task priorities while preserving component rules.
Show the consequence of a setting before publishing.
The portfolio record describes merchant and developer workflow research and a Tailwind-based system. These newly reconstructed views move from store workspace to theme configuration and preview. They explain the relationship between a control and its visible effect, rather than claiming to reproduce an archived wireframe set.
01 / Store workspace
Retalik⌕
01Store workspace↗
02Theme configuration↗
03Storefront preview↗
Choose a theme
Orient the merchant inside the store workspace.
02 / Theme configuration
Retalik⌕
Set up the storeStore workspace
Choose a themeTheme configuration ⌄
✓Configure content
Configure content
Group configuration around the storefront behavior it changes.
03 / Storefront preview
Retalik⌕
Preview the storefront
- Store workspace
- Review
- Theme configuration
- Review
Preview the storefront
Let the merchant judge the visible result before release.
Try the interaction
Retalik / Task & review study
Retalik01 / 03
View 01
Store workspace
Orient the merchant inside the store workspace.
Keep this context visibleStore workspace
Orient the merchant inside the store workspace.
Starting context
Set up the store
Configuration labels should not compete with store content.
Separate store content from configuration labels, validation and developer-facing references. Commerce values and settings need stable alignment.
Illustrative type-role specimenRetalik
Set up the store.
Preview the storefront.
HeadingTheme configuration
24 / 30 px · regularBodyHow can merchants and developers understand the same commerce product from different starting points?
16 / 26 px · regularLabelPreview the storefront
12 / 18 px · regularStateIncomplete configuration → identify the missing requirement → return to editing
12 / 18 px · regularPortfolio-font hierarchy illustration; the source does not establish the exact client font or token scale.
Draw a clear line between settings and implementation.
Which settings belong in merchant-facing controls and which belong in developer documentation?
Merchants need controls expressed in the language of their store. Developer-facing options and documentation should support the same feature without exposing unnecessary implementation detail inside the merchant’s task.
How can the preview show the effect of a change before it is published?
A preview gives a configuration change a visible consequence. Its usefulness depends on preserving enough context to compare the edited state with the storefront the merchant intends to publish.
Make the design-system connection explicit.
The recorded design contribution includes a reusable Tailwind foundation. A handoff should connect a merchant-facing setting to the component and content behavior it changes, so theme flexibility does not become a growing collection of incompatible UI exceptions.
For proposed Codex maintenance, identify the existing commerce component, the supported content variations and the preview state used to review it. Keep onboarding-time or SEO claims separate from the evidence needed to judge the interface.
Retalik’s story is about merchant workflows and reusable commerce UI; unverified onboarding-time promises are not treated as measured results.
Accessibility & standards
Access belongs in the design.
For Retalik, carry accessibility requirements from the core user journey into component states, prototypes and engineering acceptance criteria.
WCAG 2.2 AA · EN 301 549 · APCA · WAI-ARIA · Platform guidance
Complete the task without a mouse
Define tab order, visible and unobscured focus, named controls, table relationships and error recovery using native semantics and WAI-ARIA patterns.
Understand every state
Pair color with text or icons for selection, warnings and availability. Review text at WCAG contrast thresholds and use APCA alongside font size and weight for readability decisions.
Keep the workflow usable
Review zoom and reflow, 24 × 24 CSS-pixel minimum targets or qualifying spacing, alternatives to dragging, validation and accessible authentication where applicable.
Review scope & standards references
These are design references and review priorities, not a claim that this historical project passed a WCAG audit. Record criterion-level evidence, assistive-technology and device results, unresolved issues and retest outcomes before making a conformance statement.
APCA supplements the WCAG 2.2 contrast checks; it does not replace them. WCAG 3 remains a draft. EN 301 549 v4.1.1 is the latest published edition checked on 6 November 2026; its publication and its formal EU legal citation are separate matters. Confirm the applicable procurement or legal baseline with the client.
Outcomes & scope
What the work delivers.
- Established reusable Tailwind-based interface foundations for the commerce product.
- Designed workflows connecting store configuration, themes and storefront presentation.
- Kept merchant-facing controls and developer needs connected in the product design.
Results are described within the documented project scope. Illustrative studies are identified separately from original project artifacts.
Review & next iteration
What needs to hold up in use.
Use these questions to review Retalik against the behavior the design is intended to support.
- 01
Can a merchant understand which configuration changes the customer experience?
- 02
Are review and publication states distinguishable?
Project-specific acceptance questions for a future review, not reported usability-test results.
Reflection / Retalik
What I’d carry forward.
Seller operations and customer decisions need different views of the same commerce system. Shared foundations are useful when they preserve those different responsibilities.