Artasce Creative

Blog

  • Twenty-five years in, what hasn’t changed

    Twenty-five years in, what hasn’t changed

    Artasce Creative began in 2000 with a project called TurboGold. We’ll skip the nostalgia. What matters is the span: 25 years of building for the web, then for phones, and now alongside AI agents. Very little of our toolchain from that first year is still in use. The beliefs we started with are.

    What we changed, and why that’s fine

    We have no sentimental attachment to methods. Frameworks, languages, deployment, design tooling and the devices we design for have all been replaced, some more than once. Today we run a large part of our operations AI-first, and we build our own brands (Mademoiselle, VoyaVacations, Modolla) on a shared foundation: ArtasceOne, a single monorepo, and the Crystal Design System.

    Adopting new tools is not the hard part. Anyone can do it, and the list gets stale quickly. What deserves scrutiny is what a studio keeps while everything else turns over.

    Craft over speed

    The difference between good and great sits in the details: spacing that holds up on every screen, an error message that tells you what to do, a loading state someone thought about. Details are slow to get right, and they’re the first thing cut when a deadline tightens.

    This is why we describe AI as a force multiplier, not a replacement. It makes us faster at the work around the craft. A person still decides whether the result is right. When a tool speeds up the work, the saved time should go into more care, not into shipping sooner at the same level.

    Quiet excellence

    The best technology disappears. Nobody admires a checkout that simply works or a navigation they never had to think about. They just trust it.

    Our design system is built on that idea. The Crystal Design System gives every product a consistent set of tokens, including a spacing scale based on Fibonacci numbers, so decisions get made once and applied everywhere. It’s not there to show off. It lets a product feel coherent without calling attention to how it was made.

    We try to hold our own communication to the same standard. If a claim needs an adjective to sound impressive, it probably needs better evidence.

    Respect for attention

    Every screen, notification and form field asks for a moment of someone’s time. Treating that time as valuable has been just as true on a 2000-era desktop browser as it is on a phone today. Does this interaction have a purpose? If not, remove it.

    It applies to our own work too: short emails, clear status updates, and no meetings that could have been a paragraph. A partner who wastes your attention in the sales process will likely waste your users’ attention in the product.

    How to judge a partner by what they’ve kept

    A portfolio of current technologies tells you what a studio can do this year. It doesn’t tell you how they’ll behave when this year’s technology is replaced. Here are better questions to ask:

    • What have you stopped doing, and why? A studio that can name outdated practices it dropped has been paying attention.
    • What do you refuse to rush? Every good team has an answer. Vague answers suggest everything is negotiable.
    • How do you use AI, and where do humans decide? Look for a clear line between what is automated and what is judged.
    • How do you communicate when something goes wrong? Reliability shows up in the bad news, not the good.
    • Do you build things for yourselves? A studio that runs its own products lives with the consequences of its decisions.
    • Can you explain your work plainly? Jargon often covers for thin thinking.

    Listen for consistency in the answers. A partner whose principles are real will give you the same ones whether the topic is a brand identity, a mobile app or an automation pipeline.

    What this means for how we work

    We don’t promise timelines before we understand the work, and we don’t promise results we can’t back up. We promise the same things we promised in 2000: care in the details, technology that stays out of the way, and respect for the people using what we build.

    Tools will keep changing, and we’ll adopt the ones that help. The principles are what we expect to still be talking about in another 25 years.

    If you’re weighing partners for a web, mobile, brand or e-commerce product, we’re happy to talk through how we’d approach yours. See our work at artasce.com.

  • What we hand to AI, and what we keep

    What we hand to AI, and what we keep

    An agent will happily scaffold a checkout flow for a product nobody has decided to build. It will not object, and the code will look fine. That is the core problem with deciding where AI belongs: the output looks finished whether or not the thinking behind it was sound.

    At Artasce, we run AI-first operations. Agents are part of how we build web, mobile, brand and e-commerce products. We’ve also had to be specific about where they stop. Here is how we divide the work.

    The rule underneath the split

    Agents get work where the answer can be checked. People keep work where the answer is a judgment.

    A test either passes or it doesn’t. A refactor either preserves behavior or it doesn’t. Whether a screen feels right, whether a name will hold up, or whether a feature deserves to exist can’t be checked that way. Someone has to decide, and that someone is accountable for it.

    What agents handle well

    Scaffolding. Project structure, routing, config, component shells, API client boilerplate. This work is well-understood and tedious, and mistakes show up quickly. We point agents at our conventions and let them lay the foundation.

    Repetitive refactors. Renaming a prop across a codebase, migrating a deprecated API, moving hard-coded values onto design tokens. The task is mechanical and the scope is clear, so agents do it well and the diff is easy to review.

    First drafts. Documentation, release notes, alternate headline options, rough copy for a page. A draft gives a person something to react to. We treat it as raw material and never as a final.

    Test coverage. Agents are good at enumerating edge cases a tired developer skips, such as empty states, malformed input and boundary values. We still read the tests. A test that asserts the wrong thing is worse than no test, because it creates false confidence.

    What stays with people

    Product judgment. What to build, what to cut, and what to say no to. An agent optimizes for the request in front of it. A person weighs the request against the business, the user and the next six months.

    Visual taste. Spacing, weight, rhythm, restraint. Agents can apply a system, and our Crystal Design System gives them tokens and rules to apply. Deciding when a layout needs to break from the pattern is a human call.

    Naming. Products, features, components, even functions. A name is a small decision that every future reader inherits. Generated options can seed a conversation, but they don’t settle it.

    The final review. This one gets its own section.

    The review step between machine output and a client

    Nothing an agent produces reaches a client directly. Every piece of output has a named person responsible for it, and that person reviews it before it moves on.

    For code, the reviewer reads the diff, not the summary the agent wrote about the diff. They run the tests, then check that the tests test the right thing. They look for changes outside the requested scope, since agents sometimes tidy things nobody asked them to touch.

    For design and copy, the reviewer checks the work against the brand: the type scale, the palette, the voice. They also check facts. A confident sentence with an invented number in it is the most dangerous kind of draft, so every claim gets traced to a source or removed.

    The reviewer can approve, edit or reject. Rejecting is a normal outcome, and we don’t treat it as a failure of the process. It is the process working.

    Responsibility is the point of this step. If the person signing off can’t explain why the output is right, it isn’t ready.

    A checklist for your own workflow

    Run a task through these questions before you hand it to an agent:

    • Can the result be verified? If a test, a type check or a clear spec can confirm it, it’s a good candidate.
    • Is the scope bounded? Tasks with clear edges suit agents. Open-ended ones need a person to set direction first.
    • Is it reversible? Prefer work you can review in a diff and roll back. Be slower with anything that touches production data or money.
    • Does it need taste or context? If the right answer depends on knowing your customer, your brand or your history, keep it with a person.
    • Who owns the result? Name one human before the work starts. If you can’t, don’t delegate it.
    • What does review look like? Decide in advance what the reviewer will read, run and check. Skimming isn’t review.
    • What happens if it’s wrong and nobody notices? The higher the cost, the more of the work should stay human.

    If a task passes most of these, hand it over. If it fails the first or the fourth, keep it.

    The line will move

    Tools improve, and this division will shift with them. The questions above should hold up better than any specific list of tasks, because they ask about the work rather than the tool.

    Quality has never come from a single step. It comes from a person who cares about the result and has the authority to say it isn’t good enough yet. We use agents to give that person better material and more time to decide.

    If you’re working out where AI fits in your own product or team, we’re happy to talk it through.

  • Spacing is a decision. Make it once.

    Spacing is a decision. Make it once.

    Open the stylesheet of almost any young product and search for padding values. You will find 12px, 14px, 15px, 18px, 20px and 22px, often within the same screen. No one chose them. They are the residue of a hundred small eyeball adjustments.

    Each adjustment looked reasonable at the time. Together they make an interface that feels slightly off in a way nobody can name. This article covers how to stop that: define spacing once, as tokens, and let everything else reference it.

    Why eyeballing fails

    Eyeballing works for one page. It breaks when a second page, a second developer, or a mobile layout shows up. Without a shared set of values, every new screen restarts the negotiation.

    The cost is not just visual. A redesign becomes a search-and-replace across hundreds of one-off values. A founder asks for “a bit more room” and a developer has to guess how much, and where.

    A spacing scale removes the guessing. There are only so many valid distances, and you pick from them.

    Why we use a Fibonacci-based scale

    In the Crystal Design System, spacing follows this sequence:

    0, 4, 8, 16, 24, 40, 64, 104, 168, 272

    Look at the pattern. Starting from 8 and 16, each value is the sum of the two before it: 8 + 16 = 24, 16 + 24 = 40, 24 + 40 = 64, and so on. It is the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34) multiplied by a base of 8. The 4 is a half-step for tight spots like an icon next to its label.

    We use it for two practical reasons:

    • Steps grow with size. The gap between 8 and 16 is small. The gap between 104 and 168 is large. Small spaces stay precise, and large spaces separate sections without a dozen near-identical options.
    • Every value relates to the others. Because each step is built from the two before it, neighboring values sit together well, and mixing them on one screen rarely looks arbitrary.

    You do not need Fibonacci specifically. You need a scale with a rule behind it. A plain 4px or 8px multiple scale is a fine choice and far better than no scale.

    How to pick your base unit

    Start with the smallest distance you need to apply consistently. For most products, that is the gap between an icon and its label, or between a label and its input. In our case it is 8px, with 4px as the half-step.

    Then check three things:

    • Does the base divide cleanly into your body line height and your component heights?
    • Does it hold up on a phone, where space is scarcer?
    • Can everyone on the team remember the first four or five values without looking them up?

    If the answer to all three is yes, you have your base. Write it down and stop debating it.

    Write the scale into CSS variables

    Here is the scale as tokens, with a second layer that gives the values meaning:

    :root {
  /* Primitive scale */
  --ac-space-0: 0;
  --ac-space-1: 4px;
  --ac-space-2: 8px;
  --ac-space-3: 16px;
  --ac-space-4: 24px;
  --ac-space-5: 40px;
  --ac-space-6: 64px;
  --ac-space-7: 104px;
  --ac-space-8: 168px;
  --ac-space-9: 272px;

  /* Semantic layer */
  --ac-card-padding: var(--ac-space-4);
  --ac-stack-gap: var(--ac-space-3);
  --ac-section-padding: var(--ac-space-7);
}

.card {
  padding: var(--ac-card-padding);
}

.section {
  padding-block: var(--ac-section-padding);
}

.stack {
  display: grid;
  gap: var(--ac-stack-gap);
}

    The primitive layer holds the scale. The semantic layer says what each value is for. Components only reference the semantic layer.

    Now suppose cards feel cramped. You change --ac-card-padding from --ac-space-4 to --ac-space-5. Every card updates, and nothing else moves. That is what “a change happens in one place” means in practice.

    If you later want a different base, you edit the primitive values and the whole product follows.

    Mistakes we see most in early-stage products

    • One-off values. A 13px here, an 18px there. If a value is not on the scale, either the scale is missing something or the value is wrong. Decide which, then fix it.
    • Tokens named after pixels. A token called --space-16 breaks the moment 16 becomes 18. Use ordinal names like step-3 or semantic names like card-padding.
    • Only defining small values. Teams tokenize padding and forget section spacing. The big gaps between sections drift the most, and they shape the page rhythm.
    • Outer margins on components. A button with built-in margin-top only works in the one place it was first used. Let the parent control spacing with gap or a stack layout.
    • Too many steps. Twenty values is not a scale, it is a free-for-all. Ten is plenty.
    • Copying design-tool numbers verbatim. If a mockup says 22px, round it to the nearest step. The mockup was eyeballed too.

    Make the decision once

    A spacing scale is a small piece of work with a long payoff. An afternoon spent defining ten values and a handful of semantic tokens saves every later conversation that starts with “can we add a little more space here?”

    If you are building a product and the spacing already feels inconsistent, start with an audit. List every distinct padding and margin value in your stylesheet, and see how many you actually need. The answer is usually far fewer than you have.

    If you want a second set of eyes on your tokens, that is work we do at Artasce. Start by sending us your stylesheet.

  • Why page twenty should look like page one.

    Why page twenty should look like page one.

    Decide once

    Colours, type sizes, spacing, corner shapes, how a button behaves. When those are decided once and stored as named values, every new page draws from the same source instead of someone’s best guess.

    One change, everywhere

    If the brand colour shifts a shade, it should change in one place and appear on every page, every email and every app screen at once. Without a shared system, that same change means a week of hunting.

    It is how one studio runs many brands

    Modolla and Ember & Grain look nothing alike — a finance app and a fine-dining restaurant — yet they are built on the same underlying system. Each brand sets its own values; the structure underneath stays the same. Each brand gets its own look, and nothing has to be rebuilt to get it.

    What you get to keep

    A design system is not decoration. It is the part of the project that keeps paying back, because the twentieth page costs a fraction of the first and still looks like it belongs.

  • Your domain, your accounts, your keys.

    Your domain, your accounts, your keys.

    The domain is yours

    Register it in your name, on an account you can log in to. A studio can manage the settings, but the registration should never depend on a relationship staying friendly.

    So is the money

    Payments run through a merchant account you own. Fees, payouts and customer refunds are between you and the provider. A studio wires the checkout to it; it does not sit in the middle of your revenue.

    Hosting and content, too

    Your site should live on hosting you can see, with content in a system you can edit without asking permission. If you ever want to take the work elsewhere, the move should be a handover, not a rescue.

    Write the list at the start

    Before anything is built, list every account the project will touch and whose name it sits in. It takes ten minutes. It saves the awkward conversation two years later when someone has left and nobody can find the password.

  • Sell one product properly before you list a hundred.

    Sell one product properly before you list a hundred.

    Follow one item all the way

    Choose a product people actually buy. Take it from the collection grid to its own page, into the cart, through checkout and into the confirmation email. Every gap you find there would have appeared a hundred times over.

    The questions live on the product page

    Sizes, materials, what arrives in the box, when it ships and what happens if it does not fit. When those answers sit next to the button, fewer people leave to ask and fewer orders come back.

    The cart should remember

    People browse on a phone at lunch and buy on a laptop at night. A cart that survives a closed tab is not a luxury. It is the difference between an order and an abandoned visit nobody ever sees.

    Then scale the pattern

    Once one product works end to end, the rest of the catalogue is a matter of good data rather than new design. It is the order we work in on our own storefronts, and it is why their pages do not drift apart as they grow.

  • Why we build the first screen before we write the proposal.

    Why we build the first screen before we write the proposal.

    Pictures of websites mislead

    A static mockup always looks finished. It has no slow connection, no long product name, no thumb trying to reach a button at the bottom of the screen. The problems that matter only appear when the thing is real and in your hand.

    Pick the screen that earns the money

    For a shop it is the product page. For a photographer it is the booking step. For an app it is the moment a new user first sees their own information. We build that one screen properly, on a link you can open anywhere, before anything else is scoped.

    Then the proposal gets honest

    Once you have used one real screen, the conversation changes. You stop asking what it will look like and start asking what it should do next. The scope that follows is shorter, clearer and closer to what you actually need.

    What it does not mean

    One screen is not the product, and it is not a free sample of the whole build. It is the cheapest way for both of us to find out whether we see the same thing before anyone commits to a timeline.

  • Five things to have ready before you brief a studio.

    Five things to have ready before you brief a studio.

    Who it is for

    Not a demographic — a person. The customer who already loves you, and why. Every design decision gets easier when there is one real person to design for.

    The one job

    What must a visitor be able to do? Book, buy, ask, sign up. Pick one. A site that tries to do five things equally does none of them well.

    What exists already

    Domains, logins, an old site, a product spreadsheet, the payment account. Knowing what is there stops a studio from rebuilding what you already own.

    Three sites you envy

    Not to copy. To show what ‘good’ looks like to you. The reasons you give — ‘it feels calm’, ‘I found the price fast’ — are more useful than the links.

    A rough budget band

    It is not a negotiating move. It tells the studio whether to propose a focused first release or a complete build, and saves you both a round of guessing.

  • A beautiful homepage is only the beginning.

    A beautiful homepage is only the beginning.

    Follow one real task

    Pick a reason a customer would visit: book a portrait session, ask about a menu, find a jacket in the right size. Walk that task through every screen. A strong first impression should lead to useful detail, a clear next step and an honest confirmation.

    Answer the small questions

    Service areas, preparation, lead times and what is included often matter more than another paragraph about excellence. If a visitor has to leave to ask a basic question, the page has more work to do.

    Make the handoff clear

    A submitted inquiry is not a confirmed appointment. A draft plan is not a purchase. Say exactly what happened and who acts next. That small distinction is part of the experience, not a footnote.

    Build for the second visit

    People return with a different question. Give each service, project or article a useful address they can save and share. A site with real depth makes those return visits worthwhile.

  • A concierge needs a good first day, too.

    A concierge needs a good first day, too.

    Start with the facts

    Write down what you sell, where you work, when you are available and what happens after someone makes an inquiry. Missing information cannot become a reliable answer. If a price varies, explain what determines it rather than supplying a convenient guess.

    Give it a boundary

    Separate questions it can answer from decisions a person should make. Your published opening hours are an answer. A refund outside the policy is a decision. The handoff should tell the customer what happens next without promising an unconfirmed response time.

    Teach it your voice

    Collect three examples of how you explain your work well. Add phrases you would never use. Concrete examples help more than asking for a friendly or professional tone, because those words mean different things to different businesses.

    Keep the source current

    Whenever you change a service, update the information it uses. Read the unanswered questions regularly. They are a map of what your customers need and your website may be missing.