Designing Rory for phones

A situation worth working through

A creator opens their page on a phone while traveling, and a supporter reads it with larger text enabled. A layout that looked tidy on a desktop may now have cramped buttons, a cropped title, or a table wider than the screen. Designing for phones means checking real tasks under those constraints, not merely shrinking a desktop screenshot.

The first visit is a small moment

Someone may arrive between other activities with limited attention. They need a recognizable identity, a useful piece of work, and an understandable next action. A page does not have to show every possible feature at once.

Prioritize the reading order

Put the creator and current work before secondary information. Use descriptive links and labels that make sense without hovering. Check that images do not push all context below several screens of scrolling.

For a Rory page, the useful question is whether a visitor can understand the project before being asked to support it. That is a design test, not a promise about how every visitor behaves.

Test a real task

Ask someone to find the latest update and explain how they would follow the creator. Observe where they hesitate. Fix the specific problem instead of redesigning the whole page around a personal preference. Repeat on a narrow screen and with larger text.

Start with the first useful screen

A visitor should be able to identify the creator and understand the page without scrolling through a wall of navigation or decorative artwork. Keep the main heading readable and give the primary action enough room. Avoid placing several equal-weight buttons in a row that becomes cramped on a phone. Decide which action belongs first in this context.

Test text, media, and touch together

Long titles, larger text settings, and translated or user-written content can expose layout assumptions. Images should preserve their meaning when cropped, and tables need a readable narrow-screen treatment. Check that interactive elements are usable without a mouse. A design that only works with short sample names and perfectly sized images is not ready for real content.

Keep slow connections in mind

Use appropriately sized images and avoid making a large decorative asset a prerequisite for reading the page. The text and basic controls should become useful promptly. Test the actual published assets, not just the local mockup, because a correct layout can still feel slow if the deployed page requests unnecessarily large files or waits on extra services.

Words you can adapt

The example below illustrates the approach; it is not a customer message or testimonial. Change the details to match the actual situation. Keep the meaning accurate rather than copying a promise that does not fit your work.

A desktop browser narrowed to a small width is useful, but it does not reproduce every phone interaction. Test keyboard behavior, text enlargement, scrolling, and the way menus open and close. Avoid treating the absence of horizontal overflow as proof that the whole experience is comfortable or accessible.

Try the approach on a real example

Use one real draft, page, or project from your own work for this review. Keep a copy of the original so you can compare it with the revision. The exercise is deliberately small: it should help you make a concrete decision, not turn into a complete redesign or a new obligation to publish every day.

First, write down who is arriving and what they already know. A regular follower and a first-time visitor may interpret the same sentence differently. Give the draft to someone who has not helped create it, or read it after stepping away for a while. Ask what the page appears to offer before explaining what you intended. That difference is often where the useful editing work begins.

Next, identify the one action or understanding the draft is meant to support. Underline the sentence that communicates it. If several unrelated requests compete for attention, decide which one belongs here and move the others elsewhere. Keep any relevant limits close to the invitation. A person should not have to discover a different meaning after following the link or sending a message.

Read every promise literally. Words such as always, immediate, exclusive, free, and guaranteed can create expectations that are broader than you intended. Replace them with a precise description where needed. Check names, dates, destinations, permissions, and any claim about a product against the actual current situation. A warm tone helps, but it cannot repair an inaccurate promise or a link to the wrong page.

Then inspect the material on a phone and without the surrounding conversation. Read the heading, caption, and main action in order. If an image carries an important detail, make sure the text explains it too. If the draft depends on an earlier post, add a short introduction or a relevant link. Someone encountering it through a share should not need a private explanation to understand it.

What to check afterward

Ask testers to find a recent update, use search, and identify the next action on a small screen. Record where they hesitate or need to zoom. Measure loading separately from visual correctness: a fast page with unreadable controls and a beautiful page that takes too long both need attention.

Write down the outcome in plain language, including anything that remains uncertain. A useful review can end with a smaller change, a decision to wait, or a question that needs a better source. It does not have to end with a new post, a new tool, or a payment. Keep the lesson specific enough that you can use it the next time a similar situation occurs.