# I Split One Tattoo Text Tool Into Three Different Workflows > Source: > Published: 2026-07-17 03:43:37+00:00 At first, I assumed every tattoo text tool could share one simple workflow: Enter text, choose a style, and preview the result. That assumption worked for an early version. It also created a product that was too broad. A person comparing fonts, a person planning a name tattoo, and a person asking AI to create custom lettering may all type words into a box, but they are not trying to complete the same task. Over time, I split the original idea into three workflows: The interfaces still overlap, but the expected outputs are very different. The first user already knows what text they want. Their main questions are usually: This does not require AI generation. It needs a fast font workbench: The output is intentionally limited. It is a font reference, not a custom tattoo composition. That distinction matters because adding flowers, shadows, frames, symbols, and decorative flourishes would make the tool slower and less predictable for users who only want to compare letterforms. A name tattoo sounds like a font problem, but it often becomes a structure problem. Different inputs behave differently: For example, `Mia` can support expressive script lettering. `A.B. 2014` usually needs a more compact and structured direction. `Mia & Noah` introduces balance between two names. `Anne-Marie` should not be treated the same way as two separate words. The useful part of a dedicated name workflow is not showing every available font. It is helping the user decide what kind of lettering direction fits the structure of the name. That led me to build a focused [Name Tattoo Generator](https://aimaketattoo.com/name-tattoo-generator) that classifies the input and recommends a smaller set of directions. It does not try to replace the full font browser. It acts as a planning entry point. The third user wants something beyond a font preview. They may ask for: This is where AI generation becomes useful. It also introduces a difficult problem: the model must distinguish between text that must appear and visual instructions that must not appear as extra words. A user might enter: ``` Exact Text: Amelia ``` Then add: ``` Supporting Details: Soft shading, subtle drips, wider spacing ``` Without a clear boundary, the model may try to render parts of the supporting description as text. The interface therefore separates two fields. The characters that must appear exactly. Instructions about decoration, spacing, mood, shading, symbols, and composition. The [AI Tattoo Lettering Generator](https://aimaketattoo.com/ai-tattoo-lettering-generator) then builds a visual reference while trying to preserve the exact text character by character. This is a different product job from choosing a font. The output is no longer a simple preview. It is a custom visual direction that can support a later discussion with a tattoo artist. One reason I revisited the product structure was that search engines continued associating name, font, lettering, and text-related queries with the same broad font page. Queries such as these can look similar: ``` tattoo font generator name tattoo generator tattoo lettering generator tattoo text generator tattoo name creator ``` But the interfaces implied by those searches are not identical. A font generator should optimize for comparison. A name generator should optimize for guidance. An AI lettering generator should optimize for custom composition. Trying to make one page serve every variation can produce a page that mentions everything but performs no single task particularly well. This does not mean every keyword deserves its own route. Creating separate pages for small wording differences would produce thin and repetitive content. The split only made sense because the three workflows had different: The test I now use is: Would this user need a meaningfully different workflow, or only different wording? When the workflow is the same, it should probably remain one page. When the controls and expected result are genuinely different, a separate tool may be justified. Many products begin with a broad input box because it is the fastest way to ship. That is useful for testing. But one input box can hide several distinct jobs. The next stage is not always adding more options to the same screen. Sometimes it means removing options and creating clearer paths. In this case, the final structure became: ``` Font preview → Compare letterforms Name planning → Choose a suitable direction AI lettering → Build a custom visual composition ``` The tools are related, but they no longer pretend to be the same product. That separation has made the interfaces easier to explain, easier to maintain, and more honest about what each output can actually do. I would still start with one broad workflow. It is often the fastest way to learn whether users care about the problem at all. But I would pay closer attention to where users begin asking for different outcomes. Some users want speed and predictability. Some want guidance. Some want a custom generated composition. Those differences should eventually appear in the interface. A broad MVP is useful for discovery. A clearer set of focused workflows is useful for growth. For AIMakeTattoo, the separation now looks like this: The next challenge is not adding more options. It is making each path easier to discover and making the handoff between them feel natural.