Categories
Human-centered design Promoklip

Iterative making

You cannot achieve the best human-centered design for an interactive service without iterations. In a series of blogs, I cover the principles of human-centered work. Iterative work is an important part of that. That’s what this blog is about.

Want an update in your mailbox every month about my research? Then subscribe to my newsletter.

Getting it right in 1x

The other day I was at a meeting where two approaches were pitched on the whiteboard after a work session. One was a sort of intermediate step where a few things were temporarily taken care of. The other was the creation of a new law where issues could be thoroughly addressed properly. Both options had advantages and disadvantages. At one point, one attendee said, “We’d rather do it right the first time.”

I hear that more often in government. It doesn’t feel efficient to do things if we change it later. And it’s scary. The risk of something not being right and us as a government making mistakes (and getting in the newspaper!) is high.

Many implementing organizations have been involved in major service scandals in recent years, such as with the child care benefit, the WIA benefit or the student out-of-pocket grant. These issues have many different causes and consequences, but what they have in common is that they make organizations insecure about making new mistakes. This makes them reluctant to be creative and experiment. While that is exactly what is needed to make good services.

There are undoubtedly things in daily life that you can get right in 1x, but making services that people can use well, you can’t get that right in 1x. You have to learn, test and fine tune that as you go along. The ISO standard for human-centered design states that by repeating steps and seeking feedback in between, it is easier to achieve a desired result. By working iteratively, you can eliminate uncertainty during the conception and creation of services.

What is iterative work

Iterations literally means repetitions. When you create something, you do it in different versions. As soon as you have new information, you adapt policies, processes, systems, applications and letters again. In doing so, you reduce the risk that what you come up with will not meet the requirements of users and the societal goals at hand.

The complexity of how people interact with your service makes it impossible to fully know all the details at the start of your project. Many of the needs and expectations of users, as well as other stakeholders, only emerge during the course of the project.

It’s an interaction: as creators of services get better and better at understanding what their users need, they can devise and create something that hopefully fits that. Users can then provide feedback on that, upon which creators can adjust the services again.

Each iteration gives a better and better view of your direction and goal. Photo by Joel Fulgencio via Unsplash.

Is this just agile working, or is it not?

Yes and no.

Most government organizations now work agile when creating applications. But working agile does not yet mean that they also work in a people-oriented way and make feedback from users leading in change.

In addition, making services consists of more than technology. It is incredibly valuable that ICT systems are no longer built in the classic waterfall way and are set up in a much more flexible way. The same should be true for how we make policy, for implementing organizational processes, for sharing data between organizations and more.

By themselves, many officials are quite used to creating different versions and incorporating feedback from colleagues. Policy papers go around mailboxes and grow from version 0.1 to 0.9. But once something has version 1.0, the memo has been to the Stas, a law is in the Government Gazette, then it is – sort of – finished. If you notice at a later stage that things should have been done differently, just take a few steps back. That’s why you have to develop policy and implementation iteratively at the same time, so that one can give input to the other and vice versa.

It is precisely iterative practice in practice that provides many valuable insights. I follow an example of how to do that in my doctoral research with the Clustering National Debt Collection program.

When someone has debts with several government organizations, they can agree on one payment arrangement with the CJIB. At the back end, CJIB controls which organization receives which amount. Two years ago this payment arrangement started with a small group of claims from DUO, CJIB and CAK. Since then, a few more organizations or types of claims have been added each year.

A screen print of the CJIB website where you can make a payment arrangement. Created on March 19.

While it is unfortunate that not everyone in the Netherlands can apply for the scheme for every type of debt right away, CJIB can now learn in practice how the scheme works and what it takes on the back end to redesign the way the government collects debt. In this way, they are learning in practice how best to bundle policies and how to increasingly expand this to include more claims from other organizations. They do usage research on people currently using the scheme and learn why people do or do not persist with a scheme. They use those insights to adjust the policy and implementation of the scheme again. The experiences from the current scheme are also used in conversations with other organizations about how they can connect. In this way, the service continues to grow iteratively.

Iterative making or iterative talking?

Look, per se, in government we have quite a talent for iterative work. But working iteratively without making it gets bogged down in iterative talking. Constantly bringing things up for discussion, from different points of view, it sometimes seems like projects don’t move forward.

So many memos. Photo by Sear Greyson via Unsplash.

That is also iterative work, but not what I mean in this blog. In fact, getting real-world input and testing your idea or design with people who will use it will help move your project forward.

The best way to do that is to make things tangible. How to do that, I’ll tell you soon in an upcoming blog.

I also do my research iteratively, together with you

It is now second nature to me to work iteratively. This is also how I approach my doctoral research. Sometimes it makes me insecure: can’t I think of anything myself? I regularly have versions of articles read by others. My supervisors at the university, as well as readers of my monthly newsletter, regularly comment on preliminary insights and/or read along. Therefore, it also means working openly and transparently.

It is exciting to show something to another person that is not yet finished. You tend to immediately add a hundred things you want to improve, and to cover yourself, but what for? My experience, both with my current research and before when I did user research for DUO and the Corona app, is that people like to give feedback, to help test and help get the job done together.

How do you begin?

Start with the problem and not the solution. When it is shouted in the House of Representatives that “Organization X should also have an app,” yes, you can’t really do anything else. Therefore, start not with a product or concrete solution but with understanding the problem and start from the whole experience of your target group and not just your own organization. Engage users and then consider together what outcome you would like.

For example: it is a problem that many people in the Netherlands are in debt and cannot get out of it themselves. The government itself also plays a role in this as a creditor. How can we as a government solve this problem by collecting debt socially? The outcome: fewer people in (problematic) debt through better services! What kind of service… We design that iteratively together with users.

And: work openly! Share your work, actively seek input from stakeholders including your users. Open working is exciting for government. I previously wrote this guide on how to do this practically.

Categories
Human-centered design Promoklip

Understand users, tasks and environments

How can you make government services that are good for people? To explore this, I look at the principles of human-centered design. In a series of blogs, I’ll cover them one by one. That way, I’ll start to understand them better and better myself.

In this blog, the second principle: design is based on an explicit understanding of users, tasks and environments. What is it, how do you do it and how do you start? Read the first principle back here.

Want an update in your mailbox every month about my research? Then subscribe to my newsletter.

Elephant trails

The first time someone explained “usage” to me was accompanied by the example of elephant trails. You know them. You may use them yourself or have even made one at some point. The municipality has built a neat sidewalk, but the most convenient route is just along here, between the bushes. And there you go, off the designed path.

Jan-Dirk van der Burg made a wonderful book about it. On his website he shows how a number of elephant paths are still being hard fought by municipalities, such as in Leiden:

Photo by Jan-Dirk van der Burg of Olifantenpaadjes.nl

Van der Burg writes: “In Leiden, there is an innovative experiment with three parallel hedges, it looks a bit like a military course. The municipality only made a rookie mistake. The hedge just doesn’t connect to the pond area, so then another…”

Photo by Jan-Dirk van der Burg of Olifantenpaadjes.nl

You see: designing something is perfectly possible without considering its use.

But if you want to design human-centered , you can’t avoid looking into how people want to use something and in what context the use takes place. This is true in public spaces, but equally true with products such as electric toothbrushes or government services such as using WIA benefits.

What is usability?

This is the extent to which a system, product or service can be used by certain users to achieve certain goals with effectiveness, efficiency and satisfaction in a given context of use.

Definition usability from ISO standard 9241-210.

When designing products, systems and services, you must consider the people who will use them, as well as people who may be indirectly affected by their use. It is therefore important to first know who these people are. Building systems without understanding who will use it is one of the main causes of system failure. Thus the ISO standard human-centered design for interactive systems.

Whether products or services are useful depends on the context in which they are used. People may have different goals when performing actions with your product or service. In the blog on the principle of “Starting from the whole user experience,” I showed how his-goals, do-goals and tasks relate to each other.

I find that in practice, when people think of usability (or the English “usability”) they often think that buttons should work conveniently on a Web site. But it is much more than that. In his book ‘How easy can you make it’ Jasper van Kuijk explains this with ‘the usabilityui’. Use of a product or service has several aspects that affect each other.

Jasper van Kuijk’s usui from How easy can you make it (2024).

Van Kuijk argues that needs and goals combined with features what a product or service can do makes you use something. Interacting with a product or service allows you to achieve your goal. Next, the user experience is what it does to you while you are using it.

‘Unintended’ additional interactions

An example: in December, my husband and I decided to end our joint business. As real salaried millennials but with creative side hustles, we were also getting a bit older and the side hustles have actually not been around for a while. I went to the site of the Chamber of Commerce, through the drop-down menu to form 17 to deregister a limited liability company. The form needs to be printed, so I to the copy shop in my neighborhood. Then to the Hema for an envelope and then to find out that, yes, on New Year’s Eve the mailboxes are of course sealed, so the whole thing has to be mailed a few days later.

My goal was to write out the vof. A digital function was missing; it had to be on paper. I suspect because of the double “wet” signature. Or perhaps more simply, that digitizing this process is still in the planning stages. However, it significantly affected my user experience. With this, my visit to the Copyshop and to 2 Post-NL points became part of “the customer journey” of the CoC. There was no elephant path, indeed there was a significant detour.

Next, van Kuijk contrasts ease of use with this. This is not a separate layer of usability, but a cross-section of all the above elements. If user experience is what it did to me (emotion), then ease of use is what I could do with it at all (accessibility). Let’s face it: for Henk, my dad, signing out on paper would have been a piece of cake. He has a printer next to his desk with no dried ink and a tray with several sizes of envelopes. And who doesn’t usually start figuring out how to get the job done 1 day before the deadline either. But yes, his daughter unfortunately does.

A design strategy may be to serve the largest group, which is what many commercial companies do. Are there more potential Henks in the target group? Those don’t mind making a print, even make an extra one for their own records. Or are there more Maikes in the target group, then you lose sales if you don’t offer your services differently.

Or as Van Kuijk draws it beautifully in his book with a normal distribution:

Job variation relative to your target distribution. From: How easy can you make it by Jasper van Kuijk (2024).

But different rules apply to the government: they cannot choose who they do and do not serve. They have both Henk and Maike in their target audience. The government has to make services for everyone. I could only achieve my goal with this one organization.

The same principles apply to a variety of other products and services. An extra sink at the McDonalds at kid’s height. An e-reader (without blue light) for when you’re still reading in bed at night. Being able to pay a government fine directly with a QR code. A coffee mug with a handy push button that doesn’t leak when you slam it into your bag. Tikkies! Komoot that reads the route flawlessly and on time, while you are running in the woods and you can foolishly follow the voice. Just some products and services that fit exactly with use in context.

How do they do this?

How do the organizations behind these products and services manage to design them so that not only can people achieve their goals with them, but they are also so tasty to use?

They research how and in what context their product is used. For example, one of my favorite running apps was created by people who are avid runners themselves. They understand me and what I need. But even if you don’t match your user, you can research what someone needs and in what context they use your product or service.

For example, by:

  • Target your audience in their own environment. If you make services for students, walk into a university cafeteria and strike up a conversation. Are you working on services for people in debt? Take the time to hear the stories people are dealing with. Visit people in their own environment instead of hosting sessions in the office. It is precisely in their own environment that you understand how things impact each other. Observe how people use your service. Ask for examples and if they want to show you something, not just tell you about it.
  • Then engage in structured work to map usage information. Do focused in-depth interviews and observe several people while using existing services. Determine what their specific needs are. Fill in Van Kuijk’s usui based on your research. Let this guide the decisions you make during design.

These are also called the first two activities of human-centered design from the ISO standard.

Continue reading?

  • What is human-centered design? All the principles and activities based on the ISO standard at a glance.
  • The usui comes from: J. Van Kuijk (2024), How easy can you make it? Atlas contact.
  • Jan-Dirk van den Burg, 2011. Elephant trails. A series on the tension between planning mishaps and human instinct.