The best software development projects start with a User Story, from a User’s perspective, to help a User accomplish what really needs to get done.

When a new software project is initiated, the common train of thought is that the first thing that needs to be done is to “gather requirements.”  Technically this is true, assuming two prerequisite questions have been asked and properly answered, which are:

1. Gathered by whom?
2. Gathered from whom?

Mistake number one (and usually one of the biggest in the entire endeavor) is when the answers come from a single person, usually someone in a management capacity, who believes they know best what’s needed and how it should work, but unfortunately will never be someone who actually uses it.

The correct answers to these questions are:

1. Gathered by an experienced and highly trained, Business Analyst, System Architect, UI/UX Designer, etc. That is someone (or someones) adept at adapting real-world User needs to information technology reality.
2. Gathered from the actual people who will be required to use the new Application or System, and know what it needs to do to help them better perform their functions in an organization.

This process properly begins with the design experts asking the potential User to envision a new application in storyboard form.  “What do you see first when this program starts?”  And that question is soon followed up with many iterations of the same general question, “And then what happens?”

It’s not uncommon, like a filmmaker plotting out a movie scene by scene to actually use cards to create a “storyboard.”  It is from the creative process of imagining and envisioning these “scenes” within the application’s functions that a “storyline” emerges.  There’s a workflow logic that then comes to life.  And that’s how actual functional requirements are defined, prioritized, and documented.

But that basic storyline then needs to be thought of like a skeleton, still in need of “fleshing out” with the muscles and sinews, organs, connective tissues and bodily fluids that really bring it to life. Lasty, the “skin” that gives it its outward appearance.  That analogy is not too far off from what really needs to happen in designing a new application ready to be developed.

However, it must also be clearly understood that in software development, applications aren’t just designed as a single event, and from there the programmers just take it from there.  That was the mindset of the old Waterfall-style of software development.  Requirements would be given to a development team, and then some number of weeks, months, or even years would go by and the developers would then come back with the “finished” product.  That approach was how they discovered that over 60% of all program features developed were never even used by the Users.

Hence, the advent of Agile software development, an iterative ongoing evolutionary process, where the “Product Owner” of the new application would be an integral part of the actual development process.  They would be shown actual demos of the new application at regular intervals (called Sprints) of typically two weeks, and thus be able to provide direct feedback for what looked good, what was off the mark, new ideas to add, etc.

But again, it was best if the Product Owner was someone who was a genuine stakeholder, someone who would eventually be a User of this new application.  However, what is also true is that many applications can have more than one User Story, or storylines.

Some programs serve more than one group of users.  For example, a Customer Relationship Management (CRM) system may have modules that support a Marketing team with marketing automation, campaigns, lead generation documentation functions, etc.  The same system can also serve a Sales team’s Sales Pipeline from receipt of Leads to Closing Deals.  That same system may also then interface with a fulfillment organization, as well as Accounting & Finance.

With such a CRM system in our example, the Product Owner would need a larger team with representations of all the various stakeholders involved in the new system.  Each area needs to have their voice represented.

This is not to say that a business’s management has no voice in this process.  No, they may have very specific requirements for a system to report key metric information the company needs to see to measure business performance, progress, and operation.  But management is but one voice among many.  If they are the only voice, that is when you end up with Applications and Systems that many Users may come to despise and do their best not to use – or wore, fill in forms or screens with bogus data, just to check off the “activity” metrics.  That helps no one.

Good software programs are built around a foundation of achieving specific desired productivity goals, not merely for the measurement of employee activity.  Think about it: when new cars are designed and built, they usually start with the engines and body designs, not with the dashboards.  Those come later, and are indeed important, but later.

You could legitimately say that what is being described here is more of a “bottom-up” or grassroots-based approach – as opposed to a “top-down” type approach.  So which is better?

The truth is, these two perspectives don’t have to be in conflict.  It’s definitely true that User-driven software development, by design, gives the Users what they want; but what if what they want isn’t what the business really needs?  Conversely, what happens when upper-management wants a system build to produce information they believe they need, but have one built without ever talking to its intended Users, and end up with a system no one likes and is hesitant to use?  Obviously, neither of these scenarios are desirable.

Again, these two approaches don’t have to be in conflict.  They can both be applicable with the intent of starting from opposite ends of a spectrum and meeting in the middle for a more optimal result.

Picture this scenario.  Either the Users in an organization are pleading for some automation to improve how a business does certain functions, or management sees a need for the same goals and initiates a project to address it.  In other words, it’s less important who decides to take action than it is that everyone agrees action is needed to address a problem.

From that point management’s responsibility is going to be to establish the high-level goals – the strategy, if you will, and the resources to take action.  But that’s also when they need to ensure the right application design experts are there to subsequently sit down with the various stakeholders from each User community served, and start the design dialogues needed to craft those User Stories and Use Cases.

The User Stories are the objective basis for what will eventually become a dynamic Product Development Roadmap that a development team will turn into a functional application.  Nevertheless, it all starts with something as simple as asking a User to imagine and picture something brand new taking shape, “Once upon a time…”