A Wholistic and Aspirational Approach to Product Design
A simple disclaimer: The following ideas are not new. This is approach combines preexisting concepts and my personal experience of 15 years in the field to create a coherent and followable process that any product design team can adapt, customize or follow.
This framework is comprised of 5 phases; scope, research, design, handoff, and measure. Each phase contains 3 internal components which are prompts, outputs, and outcome.
Table of Contents
- Questions that engage and spur the designer into action. Prompts can also be used to get more information from a product manager, client or stakeholder.
- The tangible results or artifacts created from prompts.
- A result that should answer the most important question and achieve the goal of the phase.
- What is the problem to be solved?
- What is the project goal?
- What is the measurement for success?
- What is the timeline for the project?
- A shared project document for the team containing problem definitions, project goals, measurement criteria and timeline
- User stories that identify what tasks need to be completed for project completion.
A documented and shared understanding between all project team members and stakeholders identifying what the project scope is. Note: The scope may change depending on external factors but any changes should be communicated with the entire team.
- Does any research currently exist that the product designer can rely on to inform their work? Note: Research can also be extracted from internal data sources like customer support conversations, previous team research, or documentation.
- Does any new research need to be conducted? Note: Investing time and resources into new research should produce a significantly better outcome for the project
- Does the team need any new tools to be to conduct their research? New tools like session recording, user testing, and surveys should be considered if not already put into place.
- User testing sessions (In person or remote)
- Session recording reviews
- Customer surveys (In app or email)
Insights and information that create a clearer and more informed path forward for the design phase of the project. Research should be captured and distilled into project documentation.
- Does new copy need to be written?
- Who is responsible for providing copy?
- Is project copy consistent with the brand tone and voice?
- What is the customer journey?
- Can we use existing interaction patterns or do we need to design new behaviors for product or feature?
- Is the visual design inline with current brand style?
- Is there an existing design system with components or patterns that can be reused for product or feature?
- Does visual design look and feel consistent with current brand?
- Does proposed design solve the customer’s problem or goal?
- Does the customer experience? Note: Customer should achieve the goal of product or feature in a fluid and seamless way.
- Does the design team need to prototype their solution with existing customers or similar users either in person or remotely?
- Whiteboarding - (Optional) Often getting the project team together in person around a whiteboard to brainstorm ideas can improve communication and answer questions more efficiently. Whiteboarding sessions should be recorded, documented and shared with the entire team as reference material.
- Flow Diagrams - Flow diagrams will explain customer journey through product or feature in a visual and comprehensive way.
- Copywriting - (Optional) Copy can be written or provided for certain portions of the user interface. New copywriting or content should be shared with the entire project team.
- Wireframes - Wireframes to give design guidance as well as identify required user interface elements for final visual design.
- Prototypes - (Optional) In certain cases a prototype should be built to communicate more complex interactions or behaviors. This will provide the engineering team guidance as to what is expected.
- High Fidelity Mockups - High fidelity mockups should provide a visual static reference of what end product will look like.
The design phase outcome should produce artifacts which provide sufficient guidance for engineering to move forward as well as provide reference material to product managers or stakeholders.
- Does the engineering team have the design specification or documentation to move forward?
- Do meetings or presentations need to be scheduled to review product design?
- Frontend Development Note: Designers with frontend development proficiency can build out the user interface for the engineering team if will it increase efficiency, quality and performance of product or feature.
- Project Reviews Note: Engineering team, stakeholders and product managers should review work with design team so that intention is understood and why design decisions were made.
The project team has a clear understanding of design and expectations around customer experience.
- Do any new measurement tools need to be put into place? Note: This may mean setting up an analytics tool like Mixpanel, Heap or Amplitude into product.
- Do customer interviews need to be conducted? Note: If there isn’t sufficient usage or traffic in product to gain any valuable insights customer interviews may need to be conducted to determine success.
- Does the product or feature require a cadence of measurement checkins? Note: It’s very common, especially if there isn’t a lot of data, that success will take time to measure and this will require an ongoing effort.
- Appropriate analytics reports should be built and shared with team to provide insights into project success.
- Surveys as a mechanism to collect data on customer sentiment.
- More in depth customer interviews to determine success of goal or whether problem is being solved.
The measurement phase outcome should give all project team members an understanding as to whether or not the product or feature met the goal solved the problem that was documented in Phase 1.