2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- October 13, 2021
- Say What, Why, and for Whom Before How
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy.
When developers know WHO a feature is for and can identify with that user then they can often build a better feature that more fully meets that user’s needs. “Walk a mile in someone else’s shoes,” as the saying goes. When we can see the perspective of our users and empathize with them, it helps them get more of what they want from us.
Different users have different needs. They interact with the computer in different ways. These factors are important to consider, both when we are designing and building features as well as when we’re defining feature sets for release. In fact, WHO the feature is for it is particularly important when helping us define the minimal marketable feature-set (MMF) for a release.
When I’m designing a new system, one of the very first things I do is think about who is going to use the system and I jot down the different roles for the people who are going to be using the system. Then I personify those roles by giving each one a backstory. Fiction authors do something very similar, as do actors when there studying their part in a movie.
We can also explore the user’s backstory to more deeply understand a feature that we’re going to build. The goal is to build a feature that addresses the needs of a user and we do this by clearly understanding the user and understanding their needs by putting ourselves in their shoes. This can help us gain insights we might not otherwise get when building a feature.
Sometimes I like to have a little fun with this process. My wife is a filmmaker, and we have a video production studio in our home, complete with full props and costume departments. Sometimes when I’m working with the team on story writing and we get stuck, I’ll bring in some of our costumes and props so that the team can dress up and really step into the shoes of different kinds of users.
We have a lot of fun making up silly names and backstories for these users but at the same time, we’re gaining valuable insight as to how these users think so we can build features that address their needs more fully and completely.
Of course, you don’t have to go to the extremes of dressing up like a user in order to understand their needs. Empathy can come in many forms and simply visualizing what our customers want from their software can help us build features that users are satisfied with.
It’s often true that a feature is for a specific kind of user and addressing features from the user’s perspective helps us segregate features to address specific sets of needs. This can help us fine-tune features for specific types of users. Are the users subject matter experts or are they novices? Do they need step-by-step guidance or are they power users? Understanding these kinds of questions can be just as important as understanding what the features are in the first place.
Knowing WHO a feature is for and WHO a set of features are for can help us better address the needs of our users and helps us create feature sets that are more complete for a particular kind of user.
Previous Post: « Focus Stories on the What
Next Post: Know Why a Feature is Wanted »