| 
 This is a question that comes up frequently when designing interfaces: Should you use “your” or “my” when referring to things in a user interface? For example, should you use: 
 It’s actually a trick question, because often you don’t need any prefix and can just use: 
 Amazon is a good example of this in action because it’s obvious that it’s your account and your orders: But what if your product contains things that belong to you and to others – for example, a case working system that contains your cases and everyone else‘s? The problem with “my”You could use “My cases” in a navigation menu like this: My cases | All cases This seems fine on the face of it. But screens are not only accessed or referred to through a menu. For example, you might need to sign post users to their cases in an onboarding flow, email notification or help article. Saying something like “Go to my cases” is awkward and unnatural – if I told you to go to my cases, you’d think I was telling you to go to my cases, not yours. Similarly, a support agent might tell you to “Go to your cases” over chat or a phone call. This is confusing if the label in your UI says “My cases”. These issues just don’t come up when you use “your” – I’ve used “your” in multiple products over the years, and seen exactly zero issues in user research. So that’s good. “But what if the user is communicating to us using radio buttons, for example?”This is easy if we just work through a simple example: Do you want to share your profile photo? 
( ) Yes, share your profile photo 
( ) No, do not share your profile photo 
The options just don’t make sense – they read as if you’re instructing the computer to share someone else’s profile, having been asked about your own profile in the question. But it clear if you use “my” instead: Do you want to share your profile photo? 
( ) Yes, share my profile photo 
( ) No, do not share my profile photo 
In summary: 
 If you’d like to design forms that nail basic details like these, as well as super complex problems found in enterprise systems, you might like my course, Form Design Mastery. Here’s a recent testimonial from Laima, who signed up a few weeks ago: I always had a strong focus on usability, but I struggled to communicate my decisions and found it hard to convince developers and designers to prioritise inclusive design. 
 Adam’s course didn’t just align with my values, it gave me the vocabulary and practical tools I was missing.  The content is refreshingly concise and immediately applicable. I’ve already started using the principles in my daily work.  
If you’ve read Adam’s blog or posts and they resonate, this course will be a godsend. 
https://formdesignmastery.com See you soon,  | 
Join 9000+ designers, content designers and engineers who get my free weekly newsletter with evidence-based design tips (in 3 minutes or less). Mostly forms UX, but not always.
A year ago I posted this on LinkedIn: === I tell my students to avoid select boxes. Because it’s often better to use radio buttons. But students often say “But it’ll make the page too long”. Yep, but that doesn’t necessarily mean it’s bad UX. See the page I designed to let users select a course. Huge list of radio buttons. But no issues in user research whatsoever. Does this mean you should always use radio buttons? No. But most designers would balk at a design like this even though it worked...
Last week, I had a meeting with two devs and two designers. The meeting’s purpose was to let developers raise problems and get quick design decisions. One of the devs brought up an issue with a form that had conditional radio buttons. Here’s what the screen looked like (it’s a bit different to what I’m actually working on but close enough): When the user selects “Yes” it reveals a field to enter the name: If you leave it blank and submit the form, the page refreshes and shows an error: So far...
Quick one: Yesterday I sent you an email “My response to Hacker news comments”. I received a few responses asking for clarification in my second illustration – because I screwed it up. Here’s what it should have been: Enjoy,Adam