Blueprints são o mapeamento das atividades internas de uma organização e/ou dos processos de um sistema para que um serviço possa funcionar adequadamente.
Blueprints são construídos em função das atividades desempenhadas um por um usuário no sistema/serviço, ou por suas atividades recorrentes.
Imagine uma peça de teatro.
Enquanto os atores encenam a peça para o público-usuário, há inúmeros profissionais trabalhando, invisíveis à este público. Há técnicos de iluminação controlando toda a luz para que os atores e os elementos narrativos ganhem atenção; há técnicos de som controlando o áudio para que uma trilha sonora esteja tocando no momento certo, ou para que não esteja mais alta do que a voz dos atores; há contraregras para marcar a entrada e saída de cena dos atores; há maquiadores, camareiros e assistentes de camarim para auxiliá-los nas mudanças necessárias para cada momento da peça; e mesmo profissionais que são mais atuantes antes da encenação, tais como o próprio diretor, o roteirista, ou o figurinista.
Os blueprints são baseados no entendimento de que todo serviço, para funcionar bem, depende de atividades invisíveis ao usuário/consumidor. Quando se compra um produto em uma loja on-line, não basta apenas embrulhar o pedido e encaminhá-lo ao consumidor; é necessário emitir darfs para recolhimento de impostos relativos à venda, pagar estes impostos, emitir uma nota fiscal da venda do produto, encaminhar os dados da fatura para que se faça sua contabilidade, etc.; como se vê, nada em um serviço se resume apenas àquilo que o usuário vê a sua frente.
É sempre mais fácil construir um blueprint quando se tem, previamente, uma jornada do usuário. O blueprint é sempre construído em função das ações de um usuário sobre o serviço/sistema. Deve-se mapear, para cada ação, qual a evidência que comprova a ação do usuário no sistema/serviço; qual a resposta que este sistema/serviço dá para o usuário; quais processos internos são realizados em função desta ação; e o que será necessário para dar suporte ao processo, com o intruito que tudo funcione como devido. Algumas vezes pode ser necessário apontar impactos de uma ação sobre outros processos também mapeados.
A forma mais comum de um blueprint é uma tabela, mas é possível construí-los graficamente, através de diagramas de fluxo, ou mesmo combinados com wireframes esquemáticos de cada tela/interface de uma solução digital que mediatize o serviço.
A construção de um blueprint pode ser muito valiosa para determinar o fluxo do usuário ao longo da solução, e a organização/arquitetura da interface necessária para que todo o serviço funcione bem. Essa construção pode acontecer à partir da definição do MVP na Quest #4, mas é mais comum ocorrer à partir do momento que a solução começa a se tornar mais tangível, geralmente entre a Quest #6 e Quest #7, mantendo-se como uma ferramenta permanentemente útil, e utilizada até a finalização da solução.