Knowing where to start can be daunting. It does not have to be that way. That’s why we focus on design-thinking techniques. We don’t build software the old way anymore; the traditional requirements gathering process that we used to use slows build down, erodes the business value and drives a gap between business and IT professionals. Instead, we design a solution with the end customer in mind, ensuring we clearly understand the outcomes, then rapidly configure a low-code application.

So how do we identify the outcomes? Close collaboration with the business and IT is key to agreeing outcomes and framing the problem with precision.

We start with framing the opportunity; we work with you to understand your digital transformation opportunities and make recommendations. We assess the current state, work with senior stakeholders, the project sponsor and define the approach. Once you frame the opportunity, you can start to envisage how to design the solution.

We then focus in on the opportunity. If a problem is ill‑defined and/or complex, best practice is to run a Design Sprint or for smaller problem spaces, run shorter Ideation workshops to innovate solutions to the opportunity/problem during Discover; during both we create a prototype to test the solution with end users. It’s important to distinguish between complex and complicated in this context. A complex problem can involve many different groups with interrelationships, one where the implications of changes are unknown or it has not been done before. A complicated problem is one that may be technically difficult to complete and has lots of rules but the problem itself is simple. If the problem is clearly defined and/or simple then we recommend you move straight to Prepare and Build. Depending on your circumstances you may even run a Design Sprint during Prepare; in this case you will conduct many of the Discover tasks during Prepare, including defining your MLP.

During a Design Sprint you will:

• Understand the outcomes/problem space and focus on the most critical moments to solve for within a customer journey
• Map the problem, frame the critical moment (Microjourney™) and the key people (personas) then sketch potential solutions
• Generate lots of ideas before deciding on best idea
• Storyboard the scenario (future state Microjourney)
• Build a prototype and test it with users to validate

A design sprint should be preceded by conducting user research and can be augmented with outcomes workshops, performing operational walkthroughs and hosting problem solving workshops.

What happens next? Using what you have learned from applying these methods and tools, you can move onto the next step of defining your Microjourneys and Minimum Lovable Product (MLP) directly in Pega.

The related content links below provide methods and tools to help you.