Diseño centrado en el usuario y la voz del cliente


customer centered_design

If you are reading this at a Starbucks, waiting for your CTO to arrive with his MAC, as the two of you are going to have a joint design session to build the next successful app. This article is not for you.

(You believe you know 99% of what your potential customers want and your technologist is ready to listen to you through 10 AGILE latte iterations, until all knowledge is synched and design is crisp and ready for production)

But for the majority of us involved in IT projects where stakeholders are arrayed in a succession of tollgates, from corporate sponsors and project management officers all the way down to testers and implementation support specialists; it is harder to deliver value to customers if this collective challenge is not met via a mix of IT delivery approaches (AGILE, UX, etc.) and business process improvement techniques (Lean/ 6 Sigma, BPM, etc.)

Combining Customer Centered Design (CCD) and the 6 Sigma’s Voice of the Customer at different stages of the project lifecycle is a good example of adjusting techniques to match the different thinking patterns of business and IT stakeholders.

In an IT initiative that has customers as end users there are two critical objectives:

1) We need to understand what a customer wants (Customer Satisfaction Expectations)

2) We need to deliver a product that satisfies this need (Customer Satisfaction Experience)

The Voice of the Customer (VoC) technique addresses the first objective and is readily embraced by business stakeholders. They would be very open to follow the linear workflow of this technique, because it accommodates their own reporting structure...

VOC Workflow:

Set up strategic alignment Set up strategic alignment on where the business is willing to go (Voice of the customer might be the guiding light, but Voice of the Board sets the strategic boundaries and context for the initiative)

Gather and Analyze data Gather and analyze data to obtain actionable feedback (Usually business data is analyzed first, as a prelude to carrying out a very focused customer survey)

Disseminate insights Disseminate insights across all business units and set actions in motion

Review results Review results via other surveys and/or changes in VoC metrics.

Notice how the emphasis is on backing up with data the identification of a business need and the validation of project results, not so much on thinking how will the product satisfy the customer need.

On the other hand, IT delivery stakeholders are at greater ease with the “how”. They can build on the VoC strategic insights established by the business side, and within the boundaries set by governance; they can set off a Customer Centered Design (iterative) workflow that maximizes customer experience:

Customer Centered Design Workflow:

Contextual design study Contextual design study

Competitor product analysis Competitor product analysis

UI design and prototype testing UI design and prototype testing

Usability requirements Usability requirements

Software Implementation Software Implementation (1)

Usability tests with early product versions Usability tests with early product versions (2)

Change requests Change requests (3)

Change requests Back to (1) until all change requests are completed

An effective Business Analyst would need to be capable of facilitating both techniques during the project lifecycle, switching the deck of cards at different stretches, depending on stakeholders and project deliverables.

The illustration below portraits a high level view of how a business analyst would manage requirements and validate a solution for the project team, combining VoC and CCD:


Voice of Customer and Customer Centered Design

First, business analyst would use VoC to deliver enterprise analysis (Business Case) and the requirements baseline validated by business owners (BRD). Next, the analyst would facilitate iterative sessions between IT and sample customers, as they assess gaps in design and deliver product (This is all done within the boundaries set by Business Case and BRD). Finally, after these Customer Centered Design sprints are completed and product is released, Business Analyst will support assessment and validation of the solution via VoC surveys and gathered metrics.

It is important to make an observation in contrast with our “Starbucks scenario” mentioned at the beginning: In a pure AGILE product lifecycle, the boundaries for CCD (desirability, viability, and feasibility) are all handled simultaneously during the sprint, because business sponsors, owners, and technologists are having the lattes together. In more complex organizations, the Business Case and the BRD will contain the viability boundary and the Business Analyst will have to take on the business role and alert project management on change requests that need to be reviewed by owners and sponsors.

Unfortunately, this is the most AGILE it can get for many organizations.

   July 24th, 2013 By Larry Velarde, CBAP®




Leverforce  Copyright 2016 Leverforce Inc. Reservados todos los derechos. CBAP® es una marca registrada perteneciente al International Institute of Business Analysis. La marca de esta certificación es utilizada por los analistas de negocio que poseen la certificación CBAP, con el permiso expreso del International Institute of Business Analysis. IIBA®, el logo IIBA®, BABOK® y Business Analysis Body of Knowledge® son marcas registradas pertenecientes al Institute of Business Analysis. Estas marcas son utilizadas con el permiso expreso del International Institute of Business Analysis. 

Condiciones legales de uso y acceso a este sitio web

Módulos SAAS

  • Módulo: Necesidad de Negocio +

    Este módulo permite gestionar un listado de las necesidades de negocio asociada al análisis. Cada necesidad define lo que el cliente o el impulsor de la iniciativa (sponsor) busca obtener con los cambios solicitados en servicios TI, en términos de eliminación de problemas, mitigación de riesgos o aprovechamiento de oportunidades en su negocio. Read More
  • Módulo: Requisito de Usuario +

    Este módulo permite gestionar un listado de los requisitos de usuario asociados a una o varias necesidades de negocio. Un requisito de usuario explica un comportamiento o condición que el usuario necesita de un servicio TI para satisfacer la necesidad de negocio. Read More
  • Módulo: Requisito Funcional +

    Este módulo permite gestionar un listado de los requisitos funcionales asociados a uno o varios Requisitos de usuario. Un requisito funcional (Prefijo SLR) es la propuesta inicial del proveedor de TI que explica lo que hay que construir/cambiar en un servicio TI para que el usuario pueda disponer del comportamiento o condición solicitado en el requisito de usuario.. Read More
  • 1
  • 2
  • Modelio UML Tool +

    Leverforce permite la entrada de elementos UML (Casos de uso, Actividades, Actores, etc) desde la herramienta de modelado Modelio, vía la importación de archivos XMI. Read More
  • JIRA Issues +

    Set up JIRA projects from Leverforce’s SLA or Product Increment Modules. Read More
  • 1