This is an example of a digital product development workflow based on three aspects.
Understanding
Conceptualising
Execute and measure
The main idea is to involve the whole engineering team from the first project concept workshops to increase the sense of belonging and a collaborative working style.
In this phase we run benchmark dynamics, concept studies for the design and creation sessions with project kick-off.
1- User Research
Research, Data, Findings and Benchmark
To get a good result with UX research you need to use well-structured data collection approaches. These include qualitative and quantitative research.
• Quantitative
Both research models are complementary, however, a striking feature of quantitative research is the use of data. The main goal of this research is to turn data into numbers so that they can be analysed. The UX researcher uses data to discover patterns within a group of users. In this way, they can pinpoint the preferences of the target audience.
• Qualitative
This method is more in-depth, as the product team or UX Research will use interviews and field studies to get their answers.
A usability test, which brings a group of people together to use and critique your product, is one of the qualitative research methods.
Since it involves non-numerical data, those responsible for the dynamics should conduct it with care. This is because he should not let his personal opinions influence the result.
ANALYSE THE TECHNOLOGICAL FEASIBILITY OF A CONCEPT AND BLOCKERS
DISRUPTIVE CONCEPT | CONSERVATIVE CONCEPT |
1.2- Stakeholder Workshop Ideally Design Sprint
Not always necessary if enough data or a clear scope
• Design Sprint
The big idea with the Design Sprint is to build and test a prototype in just five days. You'll take a small team, clear the schedule for a week, and rapidly progress from problem to tested solution using a proven step-by-step checklist.
A Design Sprint is like fast-forwarding into the future, so you can see how customers react before you invest all the time and expense of creating your new product, service, marketing campaign... or whatever!
But the Design Sprint is not just about efficiency. It's also an excellent way to stop the old defaults of office work and replace them with a smarter, more respectful, and more effective way of solving problems that brings out the best contributions of everyone on the team and helps you spend your time on work that really matters.
• Design Concept (Ideation)
The ideation and concept design process consists of raising as many hypotheses as possible for the creation of the minimum viable product (MVP). In other words, the proposal is to put creativity to work and gather as many ideas as possible, always focusing on the opportunity and the value proposition that the company intends to generate.
1.3- Product Management
Confluence requirements page doc
There is a simple classification structure for the features we can consider for a product, whether it is a single 'large-scale' launch or a series of product features that are planned into a roadmap.
This structure can help us when entering requirements into Confluence.
• Metric Movers
These are resources that will move your business and product metrics in a meaningful way. In most successful companies, there are specific goals and strategies behind the decision to invest in a product or resource.
Engagement → Growth → Revenue
Typically, very few resources are actually metric drivers. We should know what they are in advance, because in the end, the judgement on whether your product or roadmap succeeded or failed will depend on the evaluation of these metrics.
• Customer Requests
These are features that our customers are actively requesting. There are no mysteries here.
We must listen to our customers and know what features they most want to see. We don't necessarily want to implement every suggestion, but as product professionals we need to listen to these direct requests with attention, humility and deep consideration.
Nothing irritates a customer more than to see the company release new features that exclude those they have already identified and actively requested.
• Customer Delight
These are features that customers didn't necessarily ask for, but are delighted when they see them. Typically, these are features that require several elements: listening to customers to understand their weaknesses, leveraging knowledge of technology to know what might be possible, and innovative design to create an unexpectedly elegant and enjoyable experience.
1.4- Design Task
Briefing (Jira)
With all the requirements described and grouped together in Confluence, we should have something for UX similar to the example below:
To Do | Studies | Research | Design | Validation | Done
When the demand arises, there will be an alignment with the PO/PM on what's coming, then you can create those tasks in the UX framework. It is important that we have a reference to the item that the PO/PM created on the team board, so that everyone can understand the actual stage that the demand is at.
After creating the tasks and setting the priorities, we can start "pulling" the items to the stage/column as the work progresses.
At the end, if there is an automation in Jira, an event can be triggered and already update the demand in the PO board.
2- Draft Design Independent File
The Product Design Specification (PDS) (Should be within the Project Requirements Document on Confluence).
Before working on producing a solution, there needs to be a thorough understanding of the actual problem identified. This document should be designed after conversations with the customer and stakeholders, and an analysis of the market and competitors.
The design team should consult it frequently for correct guidance in the later stages.
Before working on producing a solution, there needs to be a thorough understanding of the actual problem identified. This document should be designed after conversations with the client and stakeholders, and an analysis of the market and competitors.
The design team should consult it frequently for correct guidance in the later stages.
• The Product Design Concept
With the PDS document as a guide, the UX designer will begin to outline a solution.
At this stage, the product design is largely conceptual, with a key component structure in place, with details for a later stage. The details included at this stage will depend on the type of product being designed.
It is important to understand the concerns related to the product at this point. These may include activities such as manufacturing, sales and production costs, among other business things.
This initial understanding of the value chain will help eliminate or reduce rework anda multiple iterations.
At this stage, concept generation and evaluation are a vital consideration.
Multiple concepts, each meeting previously identified product requirements, are identified and evaluated to decide the best way forward.
2.1- Internal Approval
Catchups
• Concept generation and Design Critique
At this point, the designer can involve the whole engineering team and maybe stakeholders to help discuss the details of the concepts worked out in the previous stage.
A group which includes various backgrounds may end up being the most successful in terms of creative ideas and solutions. It is a good practice to encourage all ideas to be expressed, as this increases the chances of innovation.
• Do we want to test our assumptions?
With some potential concepts in hand, it's necessary to choose a suitable design that matches the product design specifications generated earlier.
This document should serve as the basis for the final design decisions.
Again, a team should be involved so that all angles of the chosen design can be evaluated.
The concept that comes closest to solving the identified problem and fulfilling the design requirements will now be developed in detail.
• The Detailed Design
At this point, the final concept has been chosen and the most obvious problems have been solved. The concept is now designed in detail with the required dimensions and specifications.
At this stage it may be important to produce one of the prototypes to test the product in close-to-real-life scenarios.
3- Android, iOS, PWA…
Cross Refinement
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work. — Scrum Guide, 2020
• Important technical points
The Backlog prioritisation work should be up to date so as not to waste time refining User Stories that will only be developed after 6 months. Important: This does not mean that the order of the stories cannot be changed for issues that arise during the refinement.
The P.O. has the chance to improve his User Stories without the haste he would do during Planning. - The P.O. can identify any User Stories "blind spots" or identify technical dependencies in time for them to be resolved.
The P.O. can add comments to User Stories for later use.
The technical team can ask questions and discuss technical aspects calmly
The technical team can request that the item be more detailed, or even split into more than one User Story.
The technical team can estimate and calmly discuss why they voted for such different efforts.
There is no obligation that all discussed items receive associated efforts in the first discussion/meeting.
• Have we reached the last stage? Not exactly.
Together with the devs, the development of our solution will leave Figma in this phase, with medium or high fidelity prototypes and as few resources as possible.
The goal of this "economy" is that the solution will be validated in an agile way, subject to usability testing and a proof of concept, all to verify if it really makes sense or not for the user.
In practice, the process ends (and starts again) when the prototype is validated by the users and discussed later in workshops with the product team.
The team shares what has been learned in the project up to that point to define a new development roadmap and product evolution with the goal of determining OKRs (Objectives and Key Results).
Last, but not least, to perfect this solution, we must move towards the Minimum Viable Product - MVP. And it is from here that we start repeating some creation, development, and validation processes.
コメント