UNIVERSAL DESIGN PROCESS

Introduction

One of the leading design research groups in the UK at the University of Cambridge and its design team focused on designing traditional products instead of conduits for marginalized groups. They also made an effort to create tools that companies can easily use in product development. One of these tools is the “Inclusive design toolkit”.
During the entire design process, the assessments and decisions made affect the level of exclusion of the design.
Many people are unable to participate in certain aspects of society, both for physical and digital issues. In order to make traditional products better and more satisfying to use, the inclusive design should be integrated into the design process (Brischetto, 2020).
According to the “cascade” model proposed by Clarkson et al. (2007) it is possible to start from a perceived need to identify possible design solutions (see Fig. 1):

    • discovery: the right design challenge by exploring the perceived needs;
    • translation: of the need in well-defined design intents, leading to the second output (the specification of the requirements);
    • creation: of preliminary concepts that are evaluated concerning the requirements, leading to the third output (concepts);
    • development: detailed design of the final product/service, ready to be produced or implemented; leading to the final output (solutions) and considering all interested parties to get to the first output (under-standing the real need).

Figure 1 – Clarkson Design process

During the entire design process, the assessments and decisions made affect the level of exclusion of the design . The toolkit, provided by the authors, aims to give knowledge and tools to reduce any possibility of exclusion. By applying the three principles of inclusive design (Clarkson et al., 2007):

    1. Recognizing exclusion;
    2. Learning from diversity;
    3. Solving for one, extending it to many by involving users in the design and considering people’s needs, the products can be usable, useful and desirable.

The involvement of the user, which implies their own knowledge,
understanding of their own needs, their desires, their empathy within, in the inclusive design process it is essential that the user can be considered the only essential component of any system.  Including the needs pf peolple in the project means starting with identification: 

    • of the group of the people who actually use, will use or will be able to use the product or system;
    • of the type -or types- of use (professional or domestic, daily or occasional etc.) to which the product is intended;
    • of the context (or contexts) of use in which the product is (or will be) predictably used.

The process of UD requires a macro view of the application being considered as well as a micro view of subparts of the application. Following is a process that can be used to apply UD (DO-IT):

    • Identify the application. Specify the product or environment to which you wish to apply universal design.
    • Define the universe. Describe the overall population (e.g., users of service), and then describe the diverse characteristics of potential members of the population for which the application is designed (e.g., students, faculty, and staff with diverse characteristics with respect to gender; age; size; ethnicity and race; native language; learning style; and abilities to see, hear, manipulate objects, read, and communicate).
    • Involve consumers. Consider and involve people with diverse characteristics (as identified in Step 2) in all phases of the development, implementation, and evaluation of the application. Also gain perspectives through diversity programs, such as the campus disability services office. Make these processes known with appropriate signage, publications, and websites.
    • Adopt guidelines or standards. Create or select existing universal design guidelines/standards. Integrate them with other best practices within the field of the specific application.
    • Apply guidelines or standards. Apply universal design in concert with best practices within the field, as identified in Step 4, to the overall design of the application, all subcomponents of the application, and all ongoing operations (e.g., procurement processes, staff training) to maximize the benefit of the application to individuals with the wide variety of characteristics identified in Step 2.
    • Plan for accommodations. Develop processes to address accommodation requests (e.g., purchase of assistive technology, arrangement for sign language interpreters) from individuals for whom the design of the application does not automatically provide access.
    • Train and support. Tailor and deliver ongoing training and support to stakeholders (e.g., instructors, computer support staff, procurement officers, volunteers). Share institutional goals with respect to diversity and inclusion and practices for ensuring welcoming, accessible, and inclusive experiences for everyone.
    • Evaluate. Include universal design measures in periodic evaluations of the application, evaluate the application with a diverse group of users, and make modifications based on feedback. Provide ways to collect input from users (e.g., through online and printed instruments and communications with staff).

A Universal Design Process – guidelines

The guidelines develop by Centre for Excellence in Universal Design  provide a precise definition of accessibility requirements for services delivered through various it channels. They also provide explanation and practical advice on techniques for implementation and testing. However, it is not enough just to have guidelines and advice. To create accessible services within time and resource budgets, developers need to follow an effective and efficient development process. This section outlines a suitable process.

This process can be followed even if there are no specific guidelines available for the technology being used. For example, there are not yet any specific guidelines for emerging technologies such as interactive television or mobile devices. In this case, accessibility requirements have to be defined and agreed at the start. This section outlines an inclusive design process that can be applied to any technology. The guidelines are organized as follows:

    1. Specify measurable accessibility targets.
    2. Specify how the service is going to be tested for compliance.
    3. Plan for maintenance and expansion.
    4. Follow an inclusive, user-centred design process.
    5. Test with real users.

1- Specify measurable accessibility targets

First, you have to define the accessibility targets that should be met. These can be documented as part of the requirements. For projects that are being put out to tender, this will be done by the service provider in the request for tenders (rft). The developer organisation can then incorporate these targets into their designers’ brief. For in-house projects, an analyst will usually define the accessibility requirements.

If the delivery technology is specifically covered by these guidelines, the accessibility targets are given here. All you have to do is choose the priority level that needs to be met. The priority 1 guidelines are considered to be the minimum level for accessibility and must always be included. In the case of the web, priority 2 guidelines should also be included if at all possible. The lowest priority guidelines are considered additional and you can pick and choose from these as appropriate for your particular project.

In some cases, the delivery technology may not be specifically covered by these guidelines. Or it may include aspects of more than one technology. However, it should be possible to define suitable requirements by borrowing from the existing guidelines. For example, interactive television is not the same thing as the web. Neither is it desktop software, public access terminals or telecoms. But it has a lot in common with these other technologies. The user interface is likely to use similar interaction methods and users are likely to face similar challenges.
If there are features that are unique to your technology, specific accessibility requirements can be devised from the universal accessibility principles:

    • All users should be able to perceive and understand the controls, instructions and outputs
    • All users should be able to reach and manipulate the controls, inputs and outputs
    • The user interface should be consistent across functions, devices and repeated use
    • For users who still cannot use the service, an equivalent alternative service should be available
    • These principles are explained in the introduction to accessibility.

2- Specify how the service is going to be tested for compliance

The requirements should also specify how accessibility is going to be measured. That is, how the resulting design is going to be assessed for compliance with the guidelines. This may be the job of a specialised testing or quality assurance team. Specifying an appropriate set of tests in advance has a number of benefits.

First, it gives the design and development teams guidance on how to check progress as they go. They can run the tests themselves during the development process so that they know they are achieving the objectives.

Secondly, it enables you to begin preparing for in depth user testing, which will involve recruiting representative users with impairments. To do this, you may have to consult with organisations that represent people with impairments and choose a suitable test environment. This may take time.

Thirdly, specifying real tests with representative users highlights the importance of the user and the tasks they will be using the system for. This helps designers understand what they are designing for.

Lastly, writing a test plan reveals how clear, objective and precise the requirements are. As far as possible the guidelines should be objective. However, this may not always be possible. For example, one of the web guidelines states “for data tables, identify row and column headers”. This is objectively measurable since it is possible to say for sure whether it has or has not been met. But the guideline “use the clearest and simplest language appropriate” is more subjective. It requires an agreement about what is “clear” and “appropriate”. In cases like this, you should try to ensure that the development and assessment teams agree on what is being asked for. It may be useful to add clarification to describe more precisely what this means in your particular situation. For example, you could state the level of literacy and knowledge of the subject area that can be assumed of the user population. Writing a precise test plan focuses attention on exactly what requirements you are measuring against.

3- Plan for maintenance and expansion

The process outlined here will help you achieve accessibility when the product or service is released. However, it is equally important that it remains accessible throughout its lifetime.

Very few services remain static. The information they provide, the customers’ needs and the technology available to meet them constantly changes. Most services therefore undergo frequent modifications or additions to content and functionality. For example, a tourist information kiosk must have its content updated weekly or monthly as theatre and cinema programs change or new tourist attractions open. A bank cash machine might be expanded to provide new services such as bill paying. The new content and functionality must be as accessible as the old.

    • Achieving this involves planning. You will need to ask questions like:
    • Who will create the new content or functionality?
    • What accessibility training or knowledge will they have?
    • What tools or assistance will they be using to guarantee accessibility?
    • Often, the people who create new content or functionality are not the same people who created the initial content or functionality. They therefore require training, tools or assistance. The kind of tools and assistance that can help guarantee accessibility are templates, content management systems, style guides, review procedures and testing.

These tools often require that the system is built in a particular way, or using particular technologies. For example, a content management system for a website requires that the site is built with a database driven architecture. So it is vital that these issues are addressed at the beginning of the project, before decisions have been made that will make it difficult to implement a particular maintenance approach.

4 – Follow an inclusive, user/human-centred design process

A user/human-centred design process is one that puts an emphasis on users and the tasks they want to perform using the service. It involves user consultation from the onset and throughout the project. It generally proceeds through rapid iterations of design, testing and redesign. This will require the participation of users who are representative of the target audience. To ensure the accessibility requirements are met, you should include people with a range of impairments.

This process will not only deliver a more usable product, it will also save time and money in the long run. It is significantly more costly and time consuming to fix a product in order to make it accessible than to develop an accessible product from scratch. Changes made late in the development process are far more costly than changes made early. The majority of these costs are not due to bugs but to unforeseen or unmet user requirements.

5 – Test with real users

To be sure that a design is accessible, it is essential to test it with real users carrying out representative tasks in a representative environment. Tests can be carried out at any stage, from early designs, through prototypes to finished implementations. Preferably, this should be done by a dedicated user testing team. Alternatively, there are organisations that specialise in user testing it products and services.


References:

    • Clarkson P. J., Coleman R., Hosking I., Waller S. , (2007). Inclusive design toolkit, UK: Cambridge Engineering Design Centre, pp. 2-5. Retrieved from: www-edc.eng.cam.ac.uk/downloads/idtoolkit.pdf.
    • Clarkson P. J., Waller S., Cardoso C., (2015). “Approaches to estimating user exclusion”, Applied Ergonomics, 46, pp. 304-310,
    • Connell, B.R., Jones, M., Mace, R., Mueller, J., Mullick, A., Ostroff, E., Sanford, J., Steinfeld, E., Story, M., Vanderheiden, G., (1997). The principles of universal design. North Carolina State University, The Center for Universal Design. http://www.ncsu. edu/project/design-projects/udi/center-for-universal-design/theprinciples-of-universal-design/
    • DO-IT – Disabilities, Opportunities, Internetworking, and Technology
    • Hirai Y., Morita Y., Elokia N., (2007). “Evaluation of usability methodologies in the universal design process”, Proceedings International Conference on Engineering Design ‘Design for Society: Knowledge, Innovation and Sustainability, CD ICED (Vol. 7), pp. 91-98.
    • Persson H., Åhman H., Yngling A. A., Gulliksen J., (2015). “Universal design, inclusive design, accessible design, design for all: different concepts-one goal? On the concept of accessibility-historical, methodological and philosophical aspects”, Universal Access in the Information Society, 14(4), pp. 505-526.
    • Centre for Excellence in Universal Design, A Universal Design Process. http://universaldesign.ie/Technology-ICT/Universal-Design-for-ICT1/A-Universal-Design-Process/
    • Sheryl B., (2015). Universal Design: Process, Principles, and Applications, How to apply universal design to any product or environment.
      DO-IT publications & University of Washington,Seattle.

      https://www.washington.edu/doit/universal-design-process-principles-and-applications

Il Curriculum è vuoto

Instructor

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *