Post

Instead, with OOUX, you base the user's experience on objects. So first you design the objects, and then you design the action to the verb using those objects. So it provides a foundation before the actions and verbs. So instead of actions first, objects first.

So, not verbing, but nouning when you look at the GDD. So instead of 'commenting', you select 'comment'. So that is the object.

So for something like an 'achievement' object, what are the core elements of an object like that? The name, the description, the badge icon, for example.

Then you add metadata necessary for that object, and you expand to more and more objects. The core elements are necessary for the objects to exist. With them, the object is meaningless.

So you focus on the objects, instead of how they are used. Then you take a look at how the various objects can be nested. So you link objects to objects. Then you add cardinality, and intentionality, to know how much an object is used in another object, and what a player should be able to do.

Then you force rank, for must haves, nice to haves etc. So you move the more important things upwards in the list.

Then you start defining interactions.

The interactions are the green stickies. Which should be in the same column as the other stickies, but this slide is 16:9 so it's to the side for now. But in the real case, it should be all in one column, per object.

Through doing this, you may find more objects you need, which is fine. That's iteration as per usual. Maybe you link to an other object, or create a new one, either can work depending on your project.

The eventual result then allows you to work on the actual interactions much more easily. So they provide a foundation, from which then to do the usual design work of prototypes, interaction design, etc.

Q&A: Do engineers directly use such objects as well? Alex: Yes, they usually do. So they can then advocate for this system too, which is helpful to keep using it internally.

Now: Joseph Kulik, about accessibility and legal compliance.

The big topic at the moment being the EAA: European Accessibility Act. Which is a directive, not a law, but some nations transposed it into law.

The timeframe is: Now. It is active. Public complaints can trigger legal action. Impact can be wide, but it isn't entirely clear yet. It is 'could' not 'has'

The application of the act is wide. Communication can mean in-game VoiP. E-commerce can mean in-game stores.

What are the requirements? EN 309 549, WCAG 2.1, and POUR

(I'm getting a feeling this can easily be weaponized. E.g. similar to zoning laws, environmental laws, which start with best intentions, and then suddenly halt all progress for years on end due to only a few public complaints.)

So, practically, what can you do? Lots of things to improve user research! Here are some checklists.

This goes even for the selection process. It is easy to accidentally discriminate against accessibility needs, and forget that you need to actively recruit for testing to make sure you're inclusive.

You may not be able to reconstruct your building to add accessible elevators, but you have other options like parking, entry, desks, equipment, etc. So this is to be able to have a user testing lab to do the tests, to get the data, to make sure you are covering the EAA.

The last talk of the day: Jessica Murrey on Scaling activism through gameplay.

First an idea of Peace, and trying to achieve it. Understanding that peace does not mean quiet, passive, or an absence of conflict. Instead to see that conflict, and think 'build', to see it as an opportunity.

And to then continually work towards that, so that folks ask you about it, which she calls 'the tattoo effect'. (Funny aside: She used an anecdote about being asked about tattoos on the street. The Europeans here all looked bewildered. That may happen in the US, but it's not a thing here.)