Apps, Software, and SaaS — Lesson 3
Features, Workflows, and User Journeys
Learning Objectives
- 1Distinguish between features and workflows.
- 2Design software requirements around user journeys rather than feature lists.
- 3Identify hidden complexity in seemingly simple workflow requests.
Features versus workflows
A feature is a capability — upload documents, send notifications, generate reports. A workflow is the sequence of steps a person uses to accomplish a goal. Successful software is designed around workflows, not feature lists.
Consider the difference: "upload documents" is a feature. "A client uploads documents, staff reviews them, missing items are flagged, the client sees which items are outstanding, and completed files are organized by project" is a workflow. The workflow reveals permissions, notification rules, file organization, status tracking, and audit needs that a simple feature request hides.
When stakeholders request features, translate them into workflows. Ask: Who starts the process? What are the steps? What happens at each decision point? Who needs to be notified? What data is created or changed? What could go wrong? These questions expose the real scope of the request.
User journeys and edge cases
A user journey maps the complete experience from first arrival to accomplished goal. For a client portal, the journey might be: receive invitation email, create account, set password, see project dashboard, upload requested documents, check approval status, download final deliverables.
Edge cases are the situations that fall outside the happy path. What if the invitation email goes to spam? What if someone tries to create an account with an email that already exists? What if they upload a file in the wrong format? What if they need to replace a file they already submitted? What if their account needs to be deactivated?
Edge cases are where projects go over budget. The happy path might take 20% of development time. Handling all the things that can go wrong takes the other 80%. Experienced teams plan for edge cases during requirements, not during testing.
From conversation to requirements
The most common project planning mistake is jumping from a conversation about goals directly to a feature list without mapping the workflow in between. Goals are too vague for developers. Feature lists are too disconnected for users. Workflows bridge the gap.
A practical approach: write down the workflow as a numbered list of steps. For each step, note the user role, the action, the data involved, the success state, and the failure state. This exercise often reveals requirements that were never discussed and questions that need answers before development begins.
If a team cannot walk through the workflow step by step in plain language, the requirements are not ready for development. The time spent clarifying workflows before building is almost always cheaper than the time spent reworking features that were built from vague requirements.
Case Study
The feature list that missed the workflow
Situation
A company requested a client portal with these features: file upload, status tracking, messaging, and invoicing. The developer built all four features. After launch, clients were confused because there was no guided workflow — all features were equally prominent, and there was no clear path from onboarding to project completion.
Analysis
The project was specified as a feature list instead of a workflow. Nobody mapped the client journey. The resulting portal was a collection of tools without a cohesive experience. Retrofitting a guided workflow after launch cost nearly as much as the original build.
Takeaway
Workflows define the experience. Features are just the tools within that experience. Always map the journey before listing the features.
Reflection Questions
- 1. Pick one process at your organization. Can you write it as a numbered workflow from start to finish? Where are the decision points?
- 2. Think about the last software feature request you made. Did you describe a feature or a workflow?
Key Takeaways
- ✓Features are capabilities; workflows are the journeys that use those capabilities.
- ✓Edge cases consume most of the development effort — plan for them during requirements.
- ✓If you cannot walk through the workflow step by step, the requirements are not ready.