User-Centered Design and Usability: Its Role in a Project

Posted June 15th, 2008 by Marco Battilana

The role of the User-Centered Design (UCD) process is vital to the success of site and/or application development yet it remains something of a foreign concept. It is also frequently bundled in with “Usability” and tacked on to the end of a project instead of taking its proper place as the underlying foundation. So, what is User-Centered Design and how should it be applied?

Let’s begin with some basic definitions:

User-Centered Design
A process focused on the design of information/tools that cater to the end user for the purposes of the most effective and efficient way of maximizing usage.
Usability
A process to validate the design of information/tools in relation to the needs determined by the user-centered design process.

Basically, user-centered design is one of the first things you’d do for a web site or web application project. Performing usability testing will validate what came out of the user-centered design process as a project goes along. It seems simple enough, but why the confusion?

To give you a better idea, here’s an example of the usual order of tasks that are performed on a typical large scale project, based on recommended UCD practices:

User-Centered Design Process

  1. Assurance of stakeholder buy-in
  2. Gathering requirements (determine scope of work and typical users)
  3. Persona development (based on typical users)
  4. Use case development (based on Personas)
  5. Usability assurance (Personas + Use case)
  6. Adjust Personas + Use case, as appropriate
  7. Information Architecture development
  8. Wireframe (Interaction design, layout design, development)
  9. Usability test (IA, Wireframe)
  10. Adjust IA and / or Wireframe, as appropriate
  11. Development (based on IA + Wireframe)
  12. Creative (Colour swatches)
  13. Wireframe + Creative (XHTML/CSS/JavaScript)
  14. Usability test (Results of Wireframe + Creative)
  15. Adjust Wireframe + Creative, as appropriate
  16. Final sign off
  17. Launch

Why the multiple references to “Usability?” Basically, it’s to reassure that the crucial choices made are validated by the best standards and practises of user-centered design. The result being that a better, more effective product is achieving what it is intending to do.

Now, let’s look at the same scenario from the project manager’s point of view. (Note: this is only one type of a typical scenario of the project manager.)

Project Manager Design Process

  1. Assurance of stakeholder buy-in
  2. Gathering requirements (scope of work as dictated by stakeholders)
  3. Persona development, based on project manager’s experiences
  4. Use case development, based on project manager’s experiences
  5. Information Architecture development
  6. Creative + Wireframe (Colour swatches, Interaction design, layout design, development)
  7. Usability test (Results of Creative + Wireframe)
  8. Final sign off
  9. Adjust Creative + Wireframe, as appropriate (if there is sufficient time)
  10. Launch

What happened? In this case, it stems from the Project manager’s role and trying to interpret what the user “thinks” they need. It’s the role of a project manager to assure that the project comes to fruition. What results is usually an end product that is built short of what the user’s needs actually are.

As well, the project manager’s route can be seen as more desirable because it has fewer steps than the recommended process. In the short run, this is very true. However, this will have some considerable impacts in the long run in regards to scalability, changing user base and/or interoperability with other systems.

It’s not a matter of confusion of the “usability” role itself. It’s more a matter of where it fits in the project plan and the associated roles and responsibilities attached.

So, what’s a team to do in the best interest of a project?

Role Transparency

The project manager design process can stem from a lack of transparency of roles. What this means is that the project manger, much like the stakeholder, graphic designer, developer, etc. all have their own skill sets, objectives and viewpoints of a project.

What can happen is that each person(s) in their respective role gives their own interpretation of what they think is needed to bring the project to fruition. From this, misinterpretations can be created from the start and the time line of the tasks and the roles associated are skewed to favour the individual creating the time line. (e.g., the project manager in this case) As a result, the project has the potential to not fully meet the needs of all involved.

By making everyone fully aware of their own roles, misinterpretations can be kept to a minimum and the tasks and roles will be associated appropriately.

Role Respect

Once everyone is aware of the roles of a project, there should be a clear idea of what’s involved from all parties and a better understanding of which person(s) is responsible for their applicable tasks, based on their skill set.

It’s not wrong for a developer cannot give feedback on a wireframe, nor for a project manager to give feedback on the visual design. Collaboration is a great thing. By fostering this type of creative atmosphere, you are able to gather all of the ideas and then leave it up to each team member to perform their job to best utilize their skills.

This way, the team is contributing and (most importantly) it’s understood which individual is best suited for the tasks involved.

Communicate, Communicate, Communicate!

It’s been said over and over again, but it’s surprising how out of touch certain members of a project team can be with the others involved. It’s overkill for everyone to get together every day, but having a weekly or biweekly roundtable to make sure everyone is on track is a great way to get a snapshot of a current situation, bring to light any issues or simply have a discussion about a particular piece of work and the best approach to complete it.

In Conclusion

It’s important not to discount the user-centered design process and usability testing as it gives a true reflection of what the user’s needs are. As well, it gives validation over multiple points of a project to assure that you are on the right track, from the user’s perspective.

In the end, assurance that the user has the best experience possible with an end product should be the ultimate goal of any product. By following the recommended user-centered design process by experienced individuals, the right steps are being taken to assure the best experience possible.


2 Responses to: “User-Centered Design and Usability: Its Role in a Project”

  1. Mel Pedley responds:
    Posted: June 17th, 2008 at 9:28 am

    Nice article! And I think the stepped UCD process you describe could definitely be useful in the type of larger scale project that often veers out of control because of the sheer size of the project team.

    The only areas I tend to remain a little concerned about are those that deal with “typical users” and “personas”. I think that this is where some of the access issues start to creep in. The “typical user” becomes too stereotypical and fails to take into account diverse access methods. As a result, although I appreciate that we need to use these abstract user models, I’m wary of processes that try to define typical users on the grounds that, in the wrong hands, they may do more harm than good.

    I’d really like to see some practical suggestions for applying these steps in a way that avoids the obvious dangers.

  2. Paul Rouke and PRWD on User Centered Design » Blog Archive » User Centered Design (UCD) Process Overview responds:
    Posted: July 31st, 2008 at 4:51 am

    […] The Role of User Centered Design and Usability in a Project […]

Sorry. Comments are closed.




Note: This is the end of the usable page. The image(s) below are preloaded for performance only.