CPUX stands for "Certified Professional for Usability and User Experience". If a candidate passes the UXQB ("International Usability and User Experience Qualification Board") exam, this means that he or she has successfully demonstrated that he or she has mastered the theoretical content defined in the various curricula - in the case of the "Advanced Levels" also the application of various methods.

In order to successfully pass the exam, a prospective UX Professional must memorize the UXQB curriculum very well. This is best done by learning with some practical examples. The curriculum consists of seven chapters divided into two blocks. The first block consists of the first two chapters. In these, the human-centered design process is covered first, followed by the topics of "Usability & User Experience".

The second larger block (5 chapters) deals with the individual phases of the human-centered design process (MZG). This describes the procedure that should be followed in order to design an interactive system (e.g., a new app) that is as user-friendly as possible. The curriculum of the UXQB is not very descriptive, as it mainly only contains definitions of terms. To counteract this and help aspiring UX professionals prepare for the exam, here's an example of how to best visualize the MZG.

Let's imagine that we have to design the screen and everything else a user interacts with (user interface) for a ticket vending machine of a railroad company. How should we proceed with this?

Phase 0:

As with any project, you should have a plan for a UX project, the UX project plan. The UX project plan contains the main deliverables and all activities to develop the UX results. It also describes the effort and human-centered quality goals to be achieved.

Phase 1:

The important thing here is to first understand and specify the context of use. Specifically, this means thinking about which users might be standing at our ticket vending machine to buy a ticket (e.g., it could be a student, a schoolchild, or a retiree). Further, we ask ourselves the following questions:

What tasks and subtasks could these users have? (e.g. solve ticket: 1. select start, 2. select destination, 3. ..., X. extract train ticket),
which destinations do they have? (e.g., visit family/friends in another city or day trip in surrounding region),
what resources are needed to buy a ticket? (e.g., time, money, ...) and
what physical and social environment might play a role? (e.g., train tracks, noisy trains, many people, ...).
This raises the question of how best to get all this information? - Interviews, observations or even focus groups are excellent ways to gather as much information as possible about the context of use. The goal is to gain a comprehensive understanding of the context of use of an interactive system.

Phase 2:

The understanding gained from Phase 1 allows us to determine a user's needs. From his point of view, we learn what he actually needs in terms of information, resources, etc., so that he can make a decision in the individual situations and ultimately become capable of acting. From this, usage requirements are derived. In these steps also a main difference lies to many other procedures in the software development. This is very often neglected.

To remain with our example (ticket vending machine): A user might need information about the price or the validity period of the ticket. We get this information from our previously made interviews or observations.

Phase 3:

In the next step, we then generate design solutions that are intended to meet the elaborated user requirements. This means that using all the collected information about users (their tasks, goals, environment, resources) and the information about their needs and usage requirements (the information about what users need to achieve their goal), the first designs are made. Often, rough drafts of the layout (wireframes) are made first. Subsequently, the work becomes more detailed, in which a prototype is built that resembles the final ticket vending machine screen. It is important here that the findings from phase 2 are taken into account. For example, information about the ticket price or its validity period must not be forgotten, otherwise the design cannot meet the identified usage requirements.

Phase 4:

In the next phase, the previously created design solutions are evaluated against the usage requirements.

In an evaluation, existing interactive systems (in this case our ticket vending machine prototype) are evaluated. It is checked if this vending machine is also user-friendly and if all our test persons can really reach their destination. Furthermore, it is also checked whether the user requirements from phase 2 were actually all fulfilled.

Once an evaluation has been carried out, it does not mean that we are finished with our ticket vending machine. During an evaluation, problems and errors are often discovered that must first be corrected. So from phase 4 we can go back to any previous phase to improve something at this point. If we notice during the evaluation of the ticket vending machine that we have forgotten to include a payment option, we should return to phase 3 and give the user the option to pay.

With this example we tried to illustrate the human-centered design process. See the UXQB exam curriculum for more detailed definitions of the terms used here.