The Life Cycle of Product Development (Agile & UCD)
Hi, my name is Michael Guild and I’ve been in the industry of technology for over 15 years now. With all my experience, I’ve decided to share my process from conceptual idea to product, at a high level, in order to help others on their journey.
The process that I like to follow is a mix of user centered design (UCD) following production guidelines of Scrum framework following agile principles.
Before starting or continuing any product, we need to answer some core questions about what we are building. And, these are some of the steps we will take along the way:
- Step1: Mission Statement
- Step 2: Target Audience
- Step 3: Usage Scenarios & Storyboarding
- Step 4: Wire-framing
- Step 5: Designing!
- Step 6: Scrum!
Step 1: The mission statement
What is the problem we are solving?
Who are the people this will effect(stakeholders/users)?
How will this add value to their lives?
These questions can be summed up in to a core mission statement. And, this mission statement will have to be referred consistently during the life cycle of the product in order to make sure we stay in alignment with our goals/targets.
Step 2: Personas & information gathering
How old are your users?
What kind of behaviors will they have?
What are the needs of these users?
What kind of skills do they posses?
What device platforms are they using?
When creating personas, we should first identify the roles of these users. For example, are they admins, buyers, sellers, anonymous, etc?
After defining roles, we then create a variety of personas that represent our target audience. When creating these persona’s, it’s nice to create character sheets, similar to dungeons and dragons. We will list their names, ages, skills, behaviors, bios, personalities, jobs, family build, locations, devices, and etc.
Step 3: Context usage and interaction scenarios
When will users want to use your product?
What kind of features would be useful to your users?
What mood will your users be in when choosing to use your product?
When reviewing your product as being the answer to a problem, you will want to create context usage or scenarios of when your defined persona’s would use your product. This can be achieved by storyboarding interactions or creating usage flow diagrams.
When creating these scenarios, think about the environments that they will be in, the devices they will be using, and what kind of moods they might have, what tasks are they trying to go though, who’s interacting with who?
Really try to grasp the user’s point of view. The key here is empathy.
Step 4: Concept Ideation
what is the minimum viable product (MVP) and is it in alignment with the product’s mission statement?
With the defined personas and interaction scenarios, we can now start thinking about the user flows with in the product and the product features that could be useful.
When creating these concept ideas, define the features and think about the importance of these features. I personally like to use sticky notes because
they allow flexibility when playing on white boards.
Each sticky note could have a Title/Name for the feature with simple bullet-points to describe the feature.
With all of these ideas that you come up with, ask yourself the following:
what is the minimum viable product (MVP) and is it in alignment with the product’s mission statement?
With that thought in mind, you can start thinking about how to wire features together and defining user workflow diagrams based on the previous personas you’ve outlined.
As you create user workflow diagrams, test them by walking though the scenarios previously defined.
You can also use sticky notes to play around with moving ui/ux elements around to experiment with layout.
Or, you could go straight into designing wireframes within a system.
Step 5: Atomic Design!
What colors speak to my audience?
What disabilities could they have?
What types user interactions are they already use to?
Prior to starting any design, we should think about theming. What are the kinds of “themes” we will need to consider for our product. Start with a Core theme and then think of variations.
A day/night theme, admin theme, user theme, etc? To define these, we should go back and reflect on your mission statement, personas, user roles, and interaction scenarios.
Defining themes should have a focus of following core principles of Atomic Design. We need to define the core Atoms (colors, typography, spacing, iconography, Form Elements, Buttons).
When designing, we should only focus o the atoms portion of Atomic Design. Referencing our Atoms and our wireframes, we can then formulate our features, pages, and interactions (molecules, organisms, and templates/pages).
Step 6: Scrum it!
What is our roadmap for MVP release candidate?
Should we start with 1 week sprints and then switch to 2 week?
Does our roadmap follow budget constraints?
Again, does our roadmap follow our initial mission statement for the MVP?
When starting a new project, I will start with either 1 or 2 week sprints, depending on the situation. If we are on tight constraints, I would suggest starting with a 1 week sprint in order to make sure we are delivering value on the initial MVP so that there is a good feedback loop to stay on the tight rope. Otherwise, doing the standard two week sprint is the defacto.
When doing Scrum, you want to follow the process, similarly to the image referenced above. Always have a sprint or 2 backlogged and roadmapped. Do high level epic feature review prior to breaking it down to finer grain requirements for stories. This requires product, design, and development to sit in the same room to review user flow diagrams, reusable ui, and cover all bases on the development side for scaling/future proofing.
Again, always refer back to these three basic & core references that were defined in the beginning of the life cycle.
Is this in alignment with our mission statement?
Are we being user centric with empathy, referencing our user personas (target audience)?
Does this add value to the core of the MVP?
As we build out, we will need to add in analytics on our Ui. This is necessary for us to get a feedback loop so we can do data driven Ui and discover how our Ui is being used vs how we intended it to be used. Also, with data driven Ui, it’s good to do Diary Studies.
In Diary Studies, we have users journal their usage scenarios, habits, feelings, motivations, behaviors, perceptions, and etc. This gives us the ability to capture more scenarios, ui changes, and ideas for new features. This is feedback that can’t be fully captured with only Ui analytics.
User diaries of daily activities gives us a log of context to understanding long-term behavior and experiences
Conclusion
By following UCD with Scrum, we can build better products for our audience, not based on our own opinions, but from the perspective of audience.
Thank you for taking the time to read this article. Please leave comments of what you would like deeper context, what I missed, or what you liked.
