As a consultant and architect, I’m privileged to be using both the User-Centered Design UCD) or Human-Centered Design (HCD) frameworks in complex projects, and it’s natural to have pondered over the difference between the two. These frameworks have helped me set aside deep-rooted biases and bring empathy into product designs which the end-users were delighted to use. I did write about the difference between Usability vs UX some time ago, though I always wanted to present a third approach to this methodology called Lead UCD that I predominantly use in the context of reactive product design strategy, in that, I’ve to strategize upon a user-friendly product within limited time and budget and with no prior knowledge of its background is critical. The challenge would be judging user behavior patterns purely based on cynical user data.
While bringing a user-centric focus on the problems individuals & teams often consider several frameworks to reach a consensus on the design in collaboration with cross-functional leads particularly in the guidance of a UCD expert. So what would be a better framework to follow – UCD, HCD or a Lean UCD? Read on.
User-Centered Design (UCD)
I came across this ‘waterfall’ model early in my career and it wasn’t until my CUA certification that I could truly comprehend its depth. It entails driving the focus of user-goals and so it’s preferable that project teams onboard a UCD expert in the product development lifecycle (PDLC) process at the very beginning.
User-centered design (UCD) or user-driven development (UDD) is a framework of processes (not restricted to interfaces or technologies) in which usability goals, user characteristics, environment, tasks and workflow of a product, service or process are given extensive attention at each stage of the design process. (from Wikipedia)
By the wording of its definition – “It’s “a framework of process not restricted to interface or technologies” UCD clearly covers every aspect of human interaction. However, for the purpose of writing this post, I’ll be referring to UCD as being related to usability engineering for product development or software development lifecycle (SDLC).
This is a derivative of the UCD framework which I had used in my consulting projects.
The immersion of UCD component in the ‘2 loops’ process of design and development, ensures user groups aren’t ignored, and the ‘waterfall’ model prevents oversight arising out of delivery/coordination hassles.
The UCD process starts at the ‘Analysis’ phase by extrapolating user needs from initial discussions as each project brings a unique challenge of perceiving user-needs and goals. In the face of a looming project timeline which is exacerbated by the absence of actual users at times, I lean heavily on user data analysis coupled with user/stakeholder interviews. The patterns in how the product was/is being used helps me to begin a UCD exercise aiming to complete the puzzle. It’s important for me to gather insights and correct the assumptions simultaneously as I move towards designing a definitive structure of the product. The ‘Analysis’ phase is complex with several tools at my disposal for gathering insights that are not limited to expert reviews, contextual inquiry, heuristic evaluation, or interviews, and I often use a combination of these tools until I have found the relevant solution. Once I have the answers the next step is to rapidly prototype the concept on a piece of paper or create a quick interactive prototype of the task-flow in Microsoft Powerpoint. These basic forms of prototyping help to get my idea across quickly to the decision-makers. At this stage, the concepts take form and an iteration/testing/refining of ideas through a collaborative exercise with the stakeholders begins. Since in a ‘waterfall’ mode the ideas have to be crystallized in order to move to the subsequent phases. In short, the ‘Visual Design’ phase integrates brand values into the final design, including software affordance, and at the ‘Coding’ stage an interactive task flow starts to create an overall experience for the users. Post the coding there’s another opportunity in a collaborative exercise to revisit the ‘Analysis’ phase, connecting the assumptions and insights with the outcome and making necessary readjustments to the product beta in accordance with user goals. A (summative) ‘Testing’ with the real users is concluded before finally launching the product, but the exercise of gaining insights and blending the functions by gaining feedback periodically continues well after the product launch phases that take the journey back to the ‘Analysis’ stage.
As a UCD Lead and by adopting this technique I have strategized in helping cross-functional teams to rationalize on user needs during the product development lifecycle by being a representative of the users in a ‘user-first’ approach.
Human-Centered Design (HCD)
I was introduced to this term while reading up on IDEO and design-thinking. The HCD process consists of a ‘co-design’ (co-creation) approach through observing users as they interact with their objects and environments and gives us insights into finding relevant creative solutions. The issues I’m referring to in particular are not limited to interactive technologies but anything that affects the society in general. In his book Change By Design, Tim Brown cites the example of American Red Cross which was concerned about its shrinking donor base and approached IDEO to find a solution. Along with Red Cross, IDEO applied the design thinking process and they were able to pinpoint the emotional factors which led people to donate blood.So by definition, it aims to connect with all the stakeholders (citizens, partners, etc) in assembling, exploring, and testing innovative methods of creation from a human perspective. It’s fair to say that HCD is a subset of ‘design thinking’ than perhaps UCD, which ensures the design solutions meet user-needs although the solutions are tested regularly with end-users. Beginning with the framing of the problem to creating the concepts collaboratively and watching the users ‘feel’ the prototype.
The Lean UCD Approach
As product development occurs in a rapidly paced IT environment it reduces iteration time for designing experiences in collaboration with users. This means the time spent in exploring features is scaled down and the UX/UCD delivery falls on the shoulders of the UX/UCD Lead and the business analysts. The ‘waterfall’ model works in a proactive engagement that affords both time and budget but not in a reactive approach where both are not just limited but the success of the engagement depends on the quality and timeliness of the delivery. Could there be a middle path to UCD and HCD? I sought out a framework in which I could collaborate with a diverse group of stakeholders in a shorter amount of time while still acquiring the tools from the UCD methodology, and without compromising on the quality of the delivery schedule or the end-result. My first decision is to create a ‘focus-group’ consisting of multi-functional stakeholders who would be at the helm of launching the product.
The ‘Scope’ is fundamentally the discovery of the product details that aren’t limited to user research but the structure of the business goals. The user groups and their immediate motivations and annoyances, basically the behavioral aspects that’d compel the product design of the product features, and also market data for deeper insights. In the ‘Analysis’ phase, I make sense of what has been gathered previously as I begin to construct the puzzle with business analysis. The biggest advantage of these two phases combined is that I spend more time gathering insights from the user-research and data analysis. Once the research has been scrutinized the next step in ‘Modeling’ is to build the prototypes and validate them against the research by working with the focus group. The feedback brings me back to the new interactions and task flows depending upon the how the research has been validated. Lastly, I ‘Design’ the framework of my UI by covering the relevant aesthetic makeover based upon the branding principles set in the corporate guidelines. I’ve purposely kept the framework generic for the designers and strategists to think and provide more inputs about the types of tools that they’d employ for each of the phases in order to get the best outcome possible. My preferred approach would is to use ‘data analysis’ along with ‘stakeholder interviews’ to connect the user needs to business objectives, but others might differ in their way of approaching the problems.
The critical difference in the Lean UCD model from the HCD / Design Thinking approach is the involvement of actual users vs dealing with user data. In several instances, it became inevitable that the project must be delivered on schedule without the participation of end-users, which means analysis of user-data and interviews remained the foundation upon which the product design outcomes depended.
So, What Works?
The methodologies, whether HCD, UCD, or Lean UCD, have been great for collaborating and setting the expectations for outcomes and in caring for a ‘user-first’ focus. My primary goal in using these methodologies is to gain empathy.
Frameworks are implemented to explore deeper insights into mental models which could be substantiated in the outcomes. For instance, HCD banks upon observing users as they interact with tools in their environment or their surroundings while stakeholders learn about their behaviours and co-design on concepts. Contrasting with the Lean UCD, where I use the ‘contextual inquiry’ methods with other tools for a quicker understanding of the problems and user behaviours, before I move to external research methods. The UCD goes further in substantiating the analysis in an elaborate ‘formative’ testing phase before diving deeper into the goals in a ‘waterfall’ mode.
So, what works and what doesn’t? It’s not about HCD vs UCD vs Lean UCD. In my opinion, it depends on the approach that organizations and teams can or cannot afford to take, based on which the decision of whether to use UCD, HCD or Lean UCD is reliant on the scope and nature of the team.
