Human-Centered Design (HCD) practices help companies develop innovative product concepts. From my experience, extending HCD practices inward to include a company’s information technology team increases the chances for success.
What is Human-Centered Design?
IDEO (a leading global design consultancy) recognizes that HCD involves viewing solutions through the lenses of Desirability, Feasibility, and Viability and building products that live at the intersection of all three lenses.
The Three Lenses of HCD:
- Desirability – What do people desire?
- Feasibility – What is technically and organizationally feasible?
- Viability – What can be financially viable?
IDEO also recognizes that solutions are developed across the phases of Hear, Create, and Deliver.
Often, HCD practitioners start by focusing on Desirability and then considering Feasibility and Viability as appropriate at later phases of the project. In general, Desirability is being identified in the Hear phase, and Feasibility and Viability are considering in the Create and Deliver phases.
Unfortunately, software products are prone to getting buried, stalled, or diluted on the path to launch due to organizational structures that challenge innovation.
Risks of not considering IT Feasibility early in the design process
I believe that innovative solutions are more likely to flourish when a team can focus on the user’s needs and goals and not be constrained by Feasibility or Viability early on. However, when working in the context of companies with established IT infrastructure, I recommend accelerating Feasibility considerations and running a research effort, in parallel with the Desirability effort, focused on IT power structures, constraints, and opportunities. If information gained from the IT research effort isn’t applied to the concrete ideas and prototypes developed in the Create and Deliver phases, a team is likely to design a solution that will be buried, stalled or diluted during implementation as authority transitions to IT.
When IT is not brought into the product development conversation early on, the negative results usually start to show up with a meeting that quickly becomes frustrating for all parties. Business leaders will schedule a meeting with IT leaders and the product development team. Business leaders and the product development team will usually lead the meeting and talk with excitement about the research and design effort. Perhaps a prototype will be demonstrated. The excitement starts to subside as it becomes clear that that IT leaders have major issues with technical underpinnings of the design solution.
Issues come up like:
- You can’t use technology X because we’re consolidating on technology Y.
- We are not able to consider deploying technology X for 6 months because of the infrastructure conversion effort.
- We can’t just release a mobile application until we determine our mobile strategy as an organization.
The meeting usually ends with IT not being able to make concrete commitments. Many meetings are likely to follow before implementation can start (if implementation starts at all). Delays and product dilution may occur as detailed issues are resolved during implementation.
The story above is a depressing one but the outcome isn’t really shocking when you consider the dynamics at play. IT should have authority over technology decisions if they are going to be responsible for the product’s performance and management. When business leaders and product development teams don’t apply a human-centered approach to understanding the power structures, preferences, and capabilities within IT, it’s likely that a product’s design will be off-balanced with consideration to Feasibility. At a human level, it’s less likely that IT leaders will seek innovative solutions to break Feasibility constraints as they may feel marginalized by not having a voice earlier in the project.
A Human-Centered Design approach to involving IT early in the design process
To increase the chances for success during implementation, I recommend including IT leaders during the Hear phase of the project. A technical research team, that includes a team member who will stay with the project through implementation, should conduct the following, non-exhaustive activities:
- Interview everyone who has authority to make decisions for every aspect of the product’s technology stack.
- Identify the roles and responsibilities of the product development team and IT.
- Understand deployment environments and processes.
1. Interview everyone who has authority to make decisions for every aspect of the product’s technology stack
Start by understanding how responsibility is organized within IT. For example, responsibility can be split between web, mobile, and data teams. Be sure to talk to everyone who has a yes/no decision when it comes to what technology can be used. Understand people’s hopes and fears when it comes to deploying new technologies. Build an understanding of how constrained or flexible technology choices will be. Building relationships and trust with the IT individuals you will be working with during implementation will invest your IT contacts in future discussion, collaboration, and support.
2. Identify the roles and responsibilities of the product development team and IT
Be sure to identify who plays what role and who will take responsibility when it comes to the product development effort. Do IT representatives give guidance and help co-create solutions or do they just approve or reject the work of the product development team? Does the product development team have the ability to assign tasks and deadlines to IT employees or do IT employees take requests from the product development team and prioritize the requests in context with requests from other projects? Understanding roles and responsibilities between the product development team and IT will help you build a staffing plan that is informed by the likely amount of leverage the product development team will get from IT.
3. Build relationships with deployment gatekeepers, and understand deployment environments and processes
In addition to IT roles governing technology decisions, it is likely that that there are IT gatekeepers and processes that govern access and deployment to different environments. It is important to identify what is required to get access to existing data or deploy to development, staging, and production environments. It is also important to understand timelines related to access requests. Sometimes it might take weeks for data to be updated in a development environment or to be approved to deploy to a staging environment. Building relationships with deployment gatekeepers and understanding their processes will allow the product development team to plan for likely access lag times and possibly gain some flexibility when necessary.
Please leave a comment to share your thoughts and observations as to how business leaders, product development teams, and IT can better collaborate to bring innovative products to market more effectively.