One of my favorite things to ask my community of more established devs in networking conversations is “what do you wish new devs knew?” Answers have led to great conversations around building relationships with a team, managing workflows and expectations, and many have been around writing and developing user stories. The first time a dev friend told me that they were putting their user stories in Jira, I was gobsmacked, since in boot camp, we were taught that user stories were just something you could toss off into a readme.
According to my teachers, user stories were useful, but not central to design, and they could just go into the docs of an MVP (minimum viable product.) I get why we were told this (the what of development is often seen as more important than the how or the why, especially for new devs, and while I don’t necessarily agree with this approach, it does make sense) but as I’ve learned different (arguably better) practices, I thought I’d start to codify some of them here, so anyone else in a bootcamp can see what’s up and be a more user-focused developer from the jump.
What (and why) is a user story?
Note: In my research, it looks like many PM frameworks and styles (Agile, Scrum, Kanban, etc) list different technical components of user stories, which I want to acknowledge, but am still researching and won’t go into much here until I know more.
At its most basic level, a good user story says what the feature will do for the user, but not necessarily how, since that’s more prescriptive. You’d want to say “a user can create an account” but not “a user will create an account by submitting to the form which will then POST to the API.” That way, if you, the developer, build the account creation flow in a different way, you’re not totally boxed into a corner by your own user story.
From my conversations, I’ve gathered that a mindful developer who’s focused on the user will have as many user stories as there are features on the application, so every part serves a purpose and can be iterated on with clarity and intention. (I also suspect designing with user stories in mind is helpful to maintain a healthy scope for a project, but what I’ve been learning about managing scope creep is going to be a different blog post!) This all ties back to something called user-centered design.
What is user-centered design?
In my research, it looks like user-centered design is exactly what it says on the tin: design that considers the user through each iterative step of the process.
This makes a ton of sense to me, a developer with a background in theater, writing, and education, fields whose success depend on the experience of a “user.” Playwrights write for an audience even if that audience is just a single reader (fun fact: this type of play is called a closet drama) and we think about not just the what but also the how and why of each beat of a user’s experience of a play, making user stories integral. Teachers write each lesson plan to be a useful tool, and considering each student’s personal user story of a lesson is a process of inclusive learning design called differentiation. Even this blog has what some writers call a speech act, or a user story to justify its existence. I’m writing this post so that hopefully some dev even newer than me will see it and put their user stories into Jira or Linear and not clog up a readme with them, even if bootcamp teachers say so. If the blog doesn’t convince a reader, then I’ve failed to provide this user story. This is all to say that user-centered design seems like a really reasonable and helpful framework, one that developers who’ve worked in a non-tech field should be able to apply pretty easily to development. That said, if there are better frameworks for app design, I’d be happy to hear about them.
Ok, cool, so where do user stories live?
All the experienced devs I’ve spoken to have mentioned putting user stories into productivity tracking software like Jira, rather than in the docs of the application, like we were taught in bootcamp. I understand this as being largely for modularity (so you can be working one user story/task and a member of your team can be working on a different one simultaneously) and scalability (if your app blows up in popularity, you’ll need a lot more space for user stories than a readme can reasonably provide.) I know I’ll be moving user stories for my application, RXGnosis, into Linear and using them more as a checklist for future development and less as a demo or narrative for the users themselves. This will also help me make my GitHub documentation easier to read- a perk!
What should the actual users see?
Actual users don’t need to see user stories. Just because it’s about them doesn’t mean that it’ll help them to see it, just like seeing a recipe for a cake doesn’t affect your experience of eating it. What you, the person eating the cake, benefit from is a totally different set of information than a recipe would give you. You'd want to know the flavor profile, the potential allergens, and the price, for example. That information for web developers is more like a User Guide, and can live in the app’s user-facing docs.
I really hope this helps other new devs think about User-Centered Design, what user stories can do, and where they can live, so our new-dev documentation can be cleaner and more intentional.
Top comments (0)