Mètodes

Problem statement

Què és?

El problem statement és una declaració explícita i ben definida del problema que es pretén resoldre en un projecte de disseny centrat en les persones.

El terme problem statement procedeix de l’enfocament Lean UX, orientat a empreses emergents o altres organitzacions que necessiten processos àgils i breus. No obstant això, el mateix concepte existeix amb diferents denominacions en altres enfocaments; per exemple, es coneix com a point of view (POI) en pensament de dissenyador o simplement com a definició del problema en altres àmbits.

Tot procés de disseny comença amb un problema que pot venir donat per un client o pot ser triat pel mateix dissenyador. En iniciar un projecte és habitual que aquest problema sigui abstracte, genèric o simplement massa ampli per a poder ser resolt.

Durant les etapes d’anàlisi i síntesi, es porten a terme diferents accions amb l’objectiu d’explorar l’espai del problema i aprendre més sobre aquest i sobre els requisits del projecte.

El coneixement recopilat servirà per a delimitar i definir el problema de disseny. Un problema ben definit està orientat sempre a l’acció, ja que indica quin és el camí que cal seguir i convida a pensar en solucions de disseny adequades al repte del projecte i els requisits acordats.

Quan?

El problem statement és el pont entre l’espai del problema i el de la solució, ja que connecta l’estat actual d’un problema amb l’estat desitjat i assenta les bases per a idear solucions.

Sorgeix de la comprensió de qui són els usuaris, quines són les seves necessitats i dificultats, i per això es concreta durant l’etapa de definició, després d’haver explorat l’espai del problema i haver investigat per identificar els requisits del disseny.

Aquest és un pas rellevant, ja que determina quin és l’enfocament que cal seguir durant l’etapa de disseny.

Quina és la seva funció?

  • Promou la generació d’idees.
  • Ajuda a exposar els diversos punts de vista dins d’un equip per alinear la visió i pactar quin és el problema més rellevant que cal resoldre.
  • Ajuda a accionar el que s’ha après durant la fase de recerca en exposar el problema de manera concreta i ben definida.
  • És una brúixola que ajuda a centrar els esforços i no desviar-se del que s’ha acordat quan sorgeixen dubtes.
  • Delimita el terreny de joc en el qual es desenvoluparà la solució: per a qui és la solució, quines són les seves necessitats i frustracions, quin impacte esperem obtenir del problem statement, etc.
  • Permet comprovar si la solució proposada dona resposta al problema principal.
  • És un element de motivació per a l’equip.

Com?

Els problem statements solen articular-se al voltant d’un problema d’usuari que s’ha identificat durant la fase de recerca, encara que també és possible fer-ho a partir d’un problema de negoci o de producte.

Intentar redactar un problem statement pot ser una tasca complexa. Abans de fer-ho podem utilitzar mètodes de definició com les 5 W, els mapes d’empatia o els mapes d’afinitat, per a sintetitzar i ordenar el que hem après durant l’exploració de l’espai del problema. També és recomanable definir els problem statements en grup sempre que sigui possible.

Charles Kettering, l’antic cap de recerca de General Motors, va dir que un problema ben definit és un problema mig resolt. Per això, una vegada que l’equip ha investigat quin és el problema actual i quines són les seves arrels, és el moment de plasmar aquest coneixement en forma de problem statement escrit.

No hi ha una fórmula única per a definir els problem statements. Algunes aproximacions de disseny han especificat el seu propi procés per a definir-los i han creat fins i tot plantilles per a redactar-los. Potser la variació més coneguda és la procedent del Lean UX: segons aquest enfocament, els problem statements es construeixen sovint basant-se en assumpcions que seran avaluades més tard amb usuaris.

Exemples

Plantilla Lean UX (per a productes existents)

[El nostre producte o servei va ser dissenyat] per aconseguir [aquests objectius]. Hem observat que el [producte o servei] no compleix [aquests objectius], la qual cosa causa [aquest efecte negatiu] al nostre [negoci]. Com podem millorar [el negoci o servei] perquè els clients tinguin més èxit basant-nos en [aquest criteri mesurable]?

Exemple

«La nostra aplicació mòbil va ser dissenyada per posar en contacte restaurants que tenen un excedent de menjar amb usuaris particulars que busquen menjar per a emportar, amb l’objectiu de reduir el desaprofitament alimentari. Hem observat que la poca oferta de col·laboradors locals en la iniciativa fa que els compradors potencials hagin de desplaçar-se fora dels seus veïnats per a recollir els lots. Això fa que molts clients dubtin de si la qualitat i la quantitat del menjar compensaran aquest esforç. Actualment solament 1 de cada 10 usuaris que consulta l’oferta de restaurants completa la compra.»

Com podem facilitar l’accés als lots de menjar i la recollida per a augmentar el 10% el nombre de comandes venudes durant tres o més mesos seguits?

Encara que aquesta fórmula va ser creada originàriament pensant en problemes de negoci, es pot adaptar fàcilment a problemes d’usuari.

Una altra fórmula habitual és la que proposa el pensament de dissenyador. A diferència de l’anterior, aquesta se centra en l’usuari.

Plantilla point of view statement (també coneguda com a user statement)

Les persones [tipus d’usuari] necessiten una forma de [descripció verbal de la necessitat] perquè [insight que hem descobert].

Exemple

«Les persones que han de menjar fora de casa diàriament i al seu lloc de treball no disposen d’una cuina per a escalfar aliments i necessiten una forma de menjar saludable i variada perquè estan cansades de menjar sempre amanides i entrepans.»

Una variació més completa d’això seria:

[Tipus d’usuari] intenta [descripció de la necessitat o objectiu] però [barrera] perquè [insight], la qual cosa el fa sentir [efecte emocional negatiu].

Independentment de la forma que prenguin, els problem statements ben definits solen tenir alguns elements en comú:

  • Especifiquen qui té el problema.
  • Esmenten quins són aquests problemes i en quin context tenen lloc.
  • Expliquen per què és important resoldre’ls.
  • Defineixen què esperem que passi quan se solucioni el problema o quin és el criteri per valorar si una solució ha estat reeixida.
  • La seva formulació és prou àmplia per a no limitar la ideació, però prou concreta per a indicar quina és la direcció correcta i quins condicionants s’han de tenir en consideració.
  • No inclouen cap solució en la formulació.

Referències

Desvos, J. (2017). «Design problem statements – What they are and how to frame them». Toptal Blog. [Data de consulta: 30 de març de 2019]. <https://www.toptal.com/designers/product-design/design-problem-statement>

Dorst, K. (2003). «The problem of design problems». Expertise indesign (pàg. 135-147).

Geunbae, L. (2017). «Designer’s indispensable skill: the ability to write and present a solid problem statement». [Data de consulta: 30 de març de 2019]. <https://uxplanet.org/designers-indispensable-skill-the-ability-to-write-and-present-a-solid-problem-statement-56a8b4b8060>

Kaminsky, A. [Data de consulta: 30 de març de 2019]. <https://www.designlibs.com/index.html#problem-statement>

Stevens, E. (2019). «How to define a problem statement: your guide to the second step in the design thinking process». Careerfoundry Blog. [Data de consulta: 30 de març de 2019]. <https://careerfoundry.com/en/blog/ux-design/stage-two-design-thinking-define-the-problem/>

Bibliografia sobre lean problem statements

Lavoie, M. (2015). «What’s your problem?: How to define a problem statement». [Data de consulta: 30 de març de 2019]. <https://medium.com/@MattPLavoie/what-s-your-problem-i45b31bf08dd>

Bibliografia sobre point of views

Dam, R.; Siang, T. (2017). «Define and frame your design challenge by creating your point of view and ask how might we». Interaction Design Foundation. [Data de consulta: 30 de març de 2019]. <https://www.interaction-design.org/literature/article/define-and-frame-your-design-challenge-by-creating-your-point-of-view-and-ask-how-might-we>

Gibbons, S. (2019). «User need statements: the “define” stage in design thinking». NN Group blog. [Data de consulta: 30 de març de 2019]. <https://www.nngroup.com/articles/user-need-statements/>