Continuous Design

What is a stream team, who is involved, who is not involved and where are they in the organisation.

Stream teams create products. But there needs to be a continuous focus on ensuring that they are headed in the right direction. We examine the daily, weekly, monthly and quarterly activities of stream teams.

It can be hard to identify where to make changes and how to approach it. We'll look at how you can convert ideas into action.

The team is responsible for their way of working. This means that they control how they work and any changes that they want to take on. There is no need for centralised sign-off.

The purpose of iterative design and the principles that underpin it.

It would be great if we could assume that every team will agree on everything. But this isn't the case. While teams should try to solve issues internally, there needs to be a process for conflict resolution.

We take a high level look at the different options available for testing assumptions and how to design your experiments.

As we continue to validate assumptions we will need to make ever more complete solutions. We'll cover the high level principles and best practices behind creating prototypes.

We'll discuss what statistical significance is, when it is necessary and, more importantly, when it is not.

Hidden data is as valuable as no data. We look at the ways that teams can communicate the process as well as the findings to ensure better understanding and buy-in.

The principles to factor in when creating compelling content.

Good information architecture enables discovery and usability. We review a few of the common techniques for enabling simple, yet comprehensive IA.

The value of good writing and how to research, write and validate your content.

Our prototypes have validated directional intent - now we need to confirm that it stays true in the real-world. But building the full product or feature could take a long time (and cost a lot). This is where Earliest Testable and Earliest Lovable Products come into play.

User Story Maps enable teams to split complex products into multiple releases in a way that aligns everyone on the current focus while also sharing the larger vision of where we are going.

It's lovely to think you will always work in an autonomous way - but you will be asked to build solutions. How should you react when there is no research, no assumptions, and no context for the solution?

When you have a vision in your head it can be tempting to design the end state and remove features. But in order to ensure the best success for each release, we need to ensure that each release is designed as a standalone product. (And chances are the end product will change along the way as well)

With multiple teams building out the same product you need a way to align people without being overly restrictive.Shared principles can help.

Accessible designs are better for everyone. We cover some of the more common accessibility tools and techniques.

We look at how teams can use design crits to help improve design effectiveness while minimising the subjectivity.

Teams need to be able to explain their decisions, even to your future selves. The important thing here is to explain the process and neglected decisions as they often provide more context than the decision itself.