Organize account settings by the change people want to make
Structure a creative-service account around profile, communication, access, and data tasks, with clear save behavior, sensitive-change verification, confirmation, and reliable return paths.
Organize around infrequent consequential tasks
Account settings collect infrequent but consequential tasks. A studio member may need to change an email address, adjust messages, review bookings, or close an account. Grouping everything beneath mysterious icons makes those tasks harder to find. Organize around recognizable changes and keep operational consequences visible where they matter.
Separate profile, account, and communication
Separate public profile information from private account details and communication choices. Decide whether changes save immediately or require an explicit save action, then apply that behavior consistently within each form. Sensitive changes may need additional verification; coordinate that requirement with the security and operations owners instead of treating it as a cosmetic extra step. Separate what the system knows from what the person has actually been told. A technically valid operation can still look unsuccessful when its confirmation is delayed or ambiguous. Describe the state before the action, while work is pending, and after it completes. Then name the information that remains available if the person leaves and returns. These notes become concrete requirements for the eventual implementation.
Change a member's contact address
Design an account area for a workshop service. Include contact details, message preferences, current bookings, and account closure. Walk through changing an email address while a booking is active. Show the pending and verified states and explain which address receives future booking information during the transition. Work through the example once from the customer's perspective, once from operations, and once after an interruption. These passes examine different assumptions; none replaces research with people who use the finished service. Preserve the same task and content across passes so that changes reveal weaknesses in the design rather than unrelated differences in the scenario. Capture each weakness as a specific revision, not a general impression.
Represent pending verification honestly
A success banner can be misleading if verification is still incomplete. A preference switch can also appear saved while a request failed. Preserve a clear current value and distinguish it from a proposed value. If closing an account affects active bookings, resolve that dependency before presenting a simple irreversible button. Distinguish a missing cue from a missing capability. Product content can explain an available recovery path, but it cannot create a recovery path the system lacks. Annotate where the interface needs a different state, a preserved value, or an operational response. Give each case a visible outcome. Otherwise an apparently helpful message may simply send someone around the same unsuccessful loop with more words to read.
Find settings through ordinary language
Review settings by assigning tasks with ordinary language, such as stop receiving exhibition announcements or update the address used for receipts. Check whether labels match those intentions and whether the result is recognizable. Keep a consistent route back to the account overview. Infrequent tasks benefit from clarity precisely because people are unlikely to remember the interface.
Worked decision
Show the current receipt address separately from an unverified replacement so a member knows where booking messages will go during the transition.
References & further reading
Examples and exercises in this guide are original teaching scenarios.
