The problem

Collaboration and decision making: Product development relied on the founder’s intuition rather than being evidence-based. New features were added without thorough evaluation and their impact wasn’t measured after release.

No mechanism for capturing feedback: Ideas from the CEO/Founder went directly to the development team without prototyping or user testing. The live site was the primary feedback channel, alongside occasional in-person events. The team only captured new feature requests from subscribers.

Lack of design guidelines: No documented design process or guidelines existed. There was no component library or even high-fidelity design files.

The process

1. Setting business goals

• Define the long-term business goal.
• Set short-term goals aligned with the long-term goal (updated quarterly).

2. Defining the problem

• Identify the most important problem to solve right now (business or user).
• Map the current state and identify opportunities for improvement.
• Define success and measurement criteria.
• Identify risks and constraints.

3. Information gathering

• Collect user insights through interviews and surveys
• Analyse usage data and competitor solutions.
• Engage key stakeholders across the business and map customer journeys.

4. Ideation (diverging)

• Generate a wide range of ideas, encouraging diverse thinking.
• Focus on concepts, not details, involving the wider team.

5. Refinement (converging)

• Seek early feedback on viability, feasibility, and usability.
• Refine ideas and create low-fidelity prototypes for user testing
• Write the user testing script and recruit suitable candidates.

6. Testing

• Test the prototype with user and based on feedback, choose one of the following paths:
  • Refine: Positive feedback indicates the solution addresses a real problem. Refine the idea based on key themes from user testing.
  • Return to Ideation: The problem is validated, but the solution falls short. Use the feedback to generate new ideas.
  • Discard: Feedback challenges assumptions from the “Defining the problem” stage, indicating this may not be the right problem to solve.

7. Implementation

• Create high-fidelity UI designs. Use existing patterns/components where possible.
• Review designs with engineers to ensure alignment and gather feedback.
• Review acceptance criteria and work closely with engineers to resolve problems that arise during implementation.
• Perform QA to ensure the final implementation aligns with the intended design and user experience.

8. Measuring the impact

• Analyse how the release has been receive by users, both comments and usage.
• Assess if success measures are met and understand reasons if not.
• If success criteria aren’t met, outline the next steps to achieve them. Alternatively, the business may decide to address any more pressing issues that have arisen.
• Review the project to identify lessons for improving future development work.

Key insights

Ideation: Design is inherently collaborative. However, in workshops I’ve found that the ideation phase is most effective when conducted independently, followed by dot voting. This approach avoids groupthink and keeps the workshop focussed.

Testing: Reaching an agreement on what is being tested is crucial. Without it, the results may be disputed by stakeholders. If agreement cannot be reached, multiple options can be tested, though it requires more time.

Defining Success and Measuring Impact: This remains an area for improvement at Stockopedia. While we review product usage and feedback on release notes, there is a tendency to move on to the next project even if the success criteria have not been met.