UD2014

Authors

Trenton Schulz, Kristin Skeide Fuglerud, Henrik Arfwedson and Marc Busch

Session

D4. Designing with technology

Date and Time

2014-06-17, 13:45 - 14:25

Room

MA 6

Presentation PDF

Long oral presentation

Transcript of the talk

>> So welcome to the session, Designing with technology. And I’m happy to introduce the first speaker, Trenton Schulz. He is going to speak about a case study for Universal Design in the Internet of things.
>> Thank you. Yes, thanks for having me. I have really enjoyed the different presentations thus far today. My name is Trenton Schulz and I’m a senior researcher at the Norwegian Computing Center, which is a research institute in Norway and we have our own little E inclusion group that takes a look at Universal Design of information technology. And today I want to talk to you about a case study for Universal Design in the Internet of things.

So the first slide I will start out with is probably something I’m not really going to discuss too much here, because I suspect that most people who are at a Universal Design conference have an idea what Universal Design means. Although I did know there was a session that was discussing the different definitions, but I guess what I really wanted to highlight are sort of two aspects that we think about Universal Design when we’re looking at information technologies. And that is one is a process, and basically this is a design process or an approach that you use to building what the other aspect is, which is you could say the result or the goal of your design, and that is that it’s possible that it can be used by as many people as possible.
So there are lots of things that one can do when one is trying to make sure that something is Universal Design. I think especially when we’re looking at ICT we look a lot at guidelines to sort of help us out with this, and like the web content accessibility guidelines. And one thing that most people are in agreement on, using these guidelines are necessary to make sure that something is universally designed or accessibility to everyone, but they’re not sufficient. You need something else. This design process needs to be sort of a holistic process and you need to sort of involve users somehow, and you need to have — there are different techniques one can use. The one I want to talk to you about today is something that many of you might know. It’s called user centered design. Now, user centered design actually has a standard that you can use. It’s called the ISO9241210. I’m sure everyone knows that ISO standard, right? I wrote it down just so I could remember.
Anyway, there are four distinct parts to user centered design if you follow the standard. So those parts are — I’ll just do a quick review. The first thing you need to do is sort of understand and specify the context where you expect your solution is going to be used. And the second set thing that you need to do is once you sort of understand this context where people are using — will be using this solution, you need to sort of specify the user requirements. And basically figure out what users need to do, what they’re required to do for this. Then you, of course, actually design the solutions that could be used and, of course, the important part here is also that you evaluate the solutions. Now, the key thing to also remember here is that you aren’t going to be doing this just once. You probably will be doing this several times, and you might see that when you’re doing this process, you might actually need to repeat some place in here and redo things. So you might find out like, oh, we totally didn’t understand this different part of the context or something and you will need to do something with that. Or that, like, oh, we missed the requirement. Or hopefully you might be in some things where there might be tweaking we need to do with the design to make it kind of work.
So the key thing to remember is there’s some sort of iterative approach. You rarely do this in one go.
So what I’m going to talk about today is mapping Universal Design, sort of the Universal Design process on to the user centered design process. And before I do that, I kind of would like to give it a context, because talking about the way, but I want to be somewhat entertaining.
This is the case we applied the subject in. It’s based on an EU project called I trust it.
And — U trust it. And users trust in the Internet of things. And basically you might ask what the Internet of things is. How many people are familiar with the Internet of things?
There’s more. I’m happy. Every time I’ve given a talk about this, more people have raised their hands. It must mean that it’s coming.
Or we’re all running away from it.

So here is a very simple scenario to kind of think about. You can think about at home you might have, let’s say, a desktop machine, a laptop, maybe a Smart Phone, tablets now, and they’re probably communicating, sharing information locally in your home.
But usually — you can start thinking of this about an Internet of things, but usually when people think about the Internet of things, they think about objects that we normally don’t think of that are connected to the Internet and everybody’s favorite objects to talk about when they start talking about the Internet or Internet of things or especially smart home, refrigerators and washing machines, not necessarily that people want these, but this is what people talk about. You can say that, okay, you might be able to control your washing machine. You might be able to get what inventory of food you need and things like that, to help you make healthier choices, run the washing machine when there’s low power and so on and so forth. But usually what will probably be happening here is that these devices are probably going to be talking to the Internet, and exchanging it with various different service providers. And we might think about this in a generic sense, but they could be talking to different companies and they could be talking to your insurance company to find out what sort of food you’re eating or if you’re going and making unsafe choices. Or it could be talking to various other institutes or organizations that it might be okay that they know some of this information, but maybe it’s not specifically about you. So what we were looking at in U Trust It is how does the user perceive trusting in these devices. There’s an interesting workshop going on in parallel about this, about smart user data, so if I wasn’t giving this presentation now I definitely would be there trying to find other things about it, because one difficult thing was getting a good idea of what “trust” was in the situation. So I just thought, before I go further I would try to say that trust here was basically a definition that we agreed on to be a user’s confidence in entities’ reliability, including acceptance of vulnerability in a potentially risky situation.
Basically, if you want to boil it down, it’s like somebody has to be sort of vulnerable and be willing to trust a technology with their information or something.
Anyway, the key thing that you might have noticed here is I used a bunch of pictures and that’s because we needed to build our own prototypes to simulate these trust situations. So we created sort of prototypes that would be working — we needed to create prototypes that would be working in Smart Home scenarios, Smart Office scenarios and we created an E-voting scenario. But one thing we set up at the beginning of the project was that the prototypes showed work for people with disabilities, or rather must work for people with disabilities, because if we think about it, if we’re going to be in this — in these Smart Homes and everything and if they’re supposed to be helping everyone, we’re going to need to make sure this information is accessible to people with disabilities because they’re going to need to use these objects too. So make sure that these objects work for everyone.

In order to help with that, we had — when we were designing the project we took contact with several different organizations to see if they would be willing to help us out with this, and we got help from two organizations in Norway for doing this. One is Dyslexia Nordia, which is the dyslexia organization in Norway and the other is the association for blind and visually impaired in Norway. So they were willing to help recruit people that would be testing out different things in the project.
So sort of introduce the case here. I’ll try to now map some of the Universal Design thing on to user centered design. There’s one other concept that I’ll bring up briefly here that I’ve sort of introduced here. It’s probably been used in other places, but we just decided to call this concept the Accessibility Champion. And this is based on some other work from another group that basically was a usability champion. And we’ve extended that idea here. And the idea of a usability champion is somebody that would be involved in your work that would basically try to be an advocate for usability during the project.
And so what we are doing here is we had our group in Norway be sort of the accessibility champions for the project to make sure that accessibility or Universal Design was not left out while we were working on things.
So I will try to highlight points where the accessibility champion did different things, although there was more than one accessibility champion.

So if we hop back to the different parts from user centered design, the first one is to understand and specify the user context or specify the context. And especially the thing that we needed to do there was sort of get people to understand the Internet of things and different contexts where they could be used or since this Internet of things didn’t quite exist at the time. So what we were doing — what we did during the project is that we recruited people and we held some focus groups and we started introducing them to the Internet of things, had them start thinking about what sort of devices could actually exist in the Internet of things and how the certain solutions could work for people in the Internet of things. So we did that for the whole project, specifically for dealing with accessibility, the accessibility champion recruited people in the focus groups for dyslexia and vision impairment and we held two focus groups for people with vision impairment and one for dyslexia and basically we went over the different scenarios, talked about how these things would work for people with vision impairment, for example, or dyslexia. The thing that was really interesting, for example, for people who had vision impairment was that in general they were very positive to all this new technology because in general they felt it was a better chance for them to be a bit more independent and they really liked the ability to actually provide input into how technology could be used.
So after we had gathered all this information and sort of figured out what sort of scenarios we could start working with in the project, we worked with step 2, which was specifying user requirements. And so we did this in two separate ways. One thing was we used a technique that has been talked about previously yesterday, which was this idea of personas. Personas or sort of these stereotypical users. They don’t actually exist but they’re sort of a composite of different types of users. So this is just an example here of some notes that we had collected from sort of a persona workshop and some skeletons that you could say of these personas. And these are a couple of the different — or these are the five personas that we created. Part of the work that was done by the accessibility champion was to sort of round out a couple of the different personas to have some different disabilities. So, for example, we had Anna up here who had about 20% vision. We also had Frederick down here who had dyslexia, but he was one of these people that was very tech heavy or he really loved technology and was about trying to find other ways of making it work without really reading the directions. We also had Paul here, who was starting to have some dementia. So some of the scenarios started working around how do we make sure that Paul is safe and things can work with him, and, for example, this was his son here was actually — he really didn’t like technology but he was kind of forced to work with it because he was dealing with Paul’s oncoming dementia. So those were most of the different ones. And then Sarah here was — I guess would be closer to the — did not have any physical disabilities but was also very quick and just wanted to get things done, so really didn’t bother with reading many things.
And the point here was part of the work that was done with the accessibility champion was making sure that the information for the different personas was correct, also updating people about what sort of technology these people would actually use so that they would have an idea of how the assistive technology would need to interact with them. Then we created some scenarios that would be used for these different situations. So here was an example of this medical cabinet that held medicine that could only be used at certain times, and how would you make sure that Paul had actually taken the medicine, things like that.
So after we had done all this work defining the requirements, having the personas, we even kept the personas around for the entire project. They would send stories out periodically to people to explain what was going on. Then it was time to produce some design solutions. And so I have a couple of pictures here where we’re sort of working on these different solutions. And part of the work that was done here by the accessibility champions was trying to make sure that the user interfaces that are shown on this screen, they’re not important, that you actually see what they really are, that there was nothing wrong with them working with, like, for example, a screen reader or things like that. Also — well, here is an example with some of the different technology that we were using, so this was, again, sort of looking at the medical cabinet and trying to, yeah — basically this was looking at the early, early prototypes and sort of the way the technology was going to be interacting with the different devices. And then here is some unknown person trying to test out some — another version of the medical cabinet, but what persons are actually trying to do here is work with an early version of the Talk Back screen reader, which had an interesting way of interacting with the screen. I don’t really need to talk too much about it. You can certainly ask me afterwards and I’ll go into great detail if you really want, but part of what was going on during this point was the — we had a hardware partner that was going to be building most of these prototypes and they needed to figure out what sort of hardware they needed to use and we also needed to figure out, okay, what sort of software is going to run on that device and, okay, what sort of assistive technology could be used, how is that assistive technology going to work out? One of the things that were interesting here was the choice of using Android and how well that was going to work with screen readers, especially the screen reader was available at the beginning of the project. As time went on in the project, the progress on that went much better, so I would say that — well, I will talk a little more in the evaluations perhaps, but it got much better and it was actually possible to actually do part 3 here with a Talk Back screen reader and that was actually evaluated against the user requirements.
So, of course, we had — we ran several user tests and we ran them actually in several different countries. We had — since we had partners in Germany, in Austria and in Norway, and we actually ran the accessibility tests all in Norway. So we had one — we did two rounds of this, of the testing. In the first round we wanted to make sure we actually had a version that we could test out, sort of ahead of time before the prototypes were done. What we did then was actually did the evaluation in virtual reality. So this picture is actually somebody trying to navigate in virtual reality. The 3D effect is kind of lost on this picture. You will just have to take my word for it. And besides, you can’t see it in the camera. You would have to see it through the person’s glasses. Of course, this is a problem if you have a visual impairment because the 3D effect and various other issues are not going to work for you. What we did for that instead is recruited primarily for dyslexia in this case and then took their feedback as far as the user interface was designed as far as the amount of text that needs to be there and the complexity of the text. So we did not — in the virtual reality thing we did not work with, like, Talk Back for that. But once we had that done and when we were still working on making sure the assistive technology was going to be good enough, we finally were able to produce the final prototypes. So this is an example of the medicine cabinet prototype here being used. And then this was — this also had the technology working with Talk Back and everything like that.
I have a very short video here that kind of covers the usability testing in Norway — or rather accessibility testing. This one was actually done by the people at the newspaper in Norway, so they were interested in Smart Homes. This is going to be a Smart Home reporting slant. The video is in Norwegian. I have subtitled it. I hope the subtitles are big enough for you to read. I am not going to do a live audio description. I apologize for people who are visually impaired and do not know Norwegian.
All that being said…

[ video playing ]

>> So the key thing there was — let me just double check.
Basically…
Yeah, that was kind of the final test we had done there. And, again, that was kind of talking about the positive use of Smart Homes and the Internet of things would be used as part of that. And then basically once we had taken all the — we had had all the evaluations, we kind of coded everything up using an open coding process and we used that to help figure out what sort of accessibility issues would be necessary and sent those on as feedback to the people. And you could — well, I will dip into that a little bit in the findings.
I’m going to quickly discuss the findings and give recommendations at the end.
So using sort of this user centered design and incorporating Universal Design into the whole process, the thing that was really interesting there it was really — it was possible to see all the places where user centered design or Universal Design was needed in each step. So we knew, like, okay, in this step we need to sort of figure out the context. Okay, how are we going to involve people with disabilities or get their opinions in? What do we do in the circumstance where we’re designing, how do we make sure that their needs are taken care of? So the thing that was really great was that we could easily see all the places where we actually needed to incorporate it instead of like, oh, well, I guess we do the accessibility stuff at the evaluation stage, which is probably too late to be looking at stuff.
I think the other thing that was interesting was the accessibility champion sort of works well. The thing that helped with is that people in different countries or different partners were able to actually, okay, I know who I need to talk to about accessibility. They knew that somebody was always going to be following this up and wasn’t going to just, like — it wasn’t going to suddenly disappear. Even if it disappeared for, like, a meeting, for example, it was going to get noticed in the meeting minutes or something and when prototypes would show up, somebody would be in charge of looking at these different accessibility issues that were there. I’ll just do a quick question about how accessible the prototypes were.
I mean, like, since it was a research project and we were doing iterations, we found problems for both accessibility and usability in the evaluations. The medicine cabinet actually had an issue that it could not have its software upgraded and it could not work well with a screen reader. So actually when we had some people there — the person in the video, for example, used a magnifying glass, but we had some people that couldn’t use magnifying glasses who actually were blind and those, like we actually would had to — we actually had to kind of sit there and read those things for them because we wanted to see how they were reacting to the trust information.
The other thing I would say, though, is that we found that was actually a usability thing on the accessibility side was just basically how we presented some information. So this is a copy of the UI, a couple of the UI screens for the project. I’ll just quickly go through it. The point was, the key here, information, what was presented first, when people had the screen presented, was the security level. So we actually read what the security level was. We said, security level is one of four or one low of four. And that was great. Because they got to know what sort of the security level was at once. But the thing that was a bit more difficult was then people, when they would try to get to the next things then they would have all this great text here, which is great to know the first time, but eventually once you’re doing activity 5 or 6, like, oh, okay, I know what this text is going to say, really what I want to do is get down to these buttons and either make my decision on continuing or not continuing. And this was something that, like, well, we thought we had it in a nice hierarchy, but we realized, once you’re doing this constantly, this hierarchy is not quite as good. So what we should have probably done is, for example, move this extra textual information after the buttons, for example, or had something — some sort of hint to indicate you could find out more information if you hopped to a different spot, so as to speak.
So these were, like, issues, but the important part was to get the accessibility information up there to that level. Then we could actually find these as real bugs instead of like, oh, I can’t read the screen at all. So we thought that was important.
If we look quickly at what sort of things could be done differently, it would have been great to have included more users with different disabilities. We realized that having people with dyslexia and vision impairment doesn’t cover all possible problems people might have had. We did try to make sure things were multi-modal and people could use them. We had two agencies recruiting and had to use what we had. There are different levels of impairment. In the video somebody was using a magnifying glass. Vision impairment impaired people, half of them used Talk Back and others used other ways, like zooming the screen or using a magnifying glass. You had to be careful in finalizing requirements. This was talking about hardware issues, that the hardware had to be finalize and at some point some hardware could not be upgraded. Then we got into a big problem and were like, but we really need this version and they would be like, no, we can’t. So we got stuck.

So sometimes you have to kind of work a bit with the hardware people to make sure that you can sort of work on some sort of compromise.
And I think the other thing that was important was that including Universal Design from the beginning makes it part of the regular project work, so nobody thought of this as like, oh, this is extra work. They just thought, this is just part of what needs to happen. So every time they would, perhaps, ask the accessibility champion, okay, I’ve done this stuff, could you maybe take a look at it now? And it worked quite well for that. Some quick recommendations before finishing.
The first is sort of determined level of user involvement when defining the project. So this is when we sort of got in contact with these different user organizations to see which would be willing to help us out during the project. So this is kind of important to determine how you want to run the project, how are you going to sort of make sure that participants can participate, make allowances for them, if they need payment, how do you do that.
Second have an accessibility champion. At least having somebody there who is constantly thinking about accessibility and making sure it doesn’t disappear is very important and it makes the work better and easier, I think overall.
And then finally — or be aware of the complexity of assistive technology and realize you have to sort of know how this assistive technology works. You need to be aware of where the shortcomings are and how to make it work, I guess. Sorry. And then finally, perform user evaluations, including people with disabilities. It doesn’t matter how well someone like me, for example, knows how Talk Back works and that I should write alternative text here or descriptive information. At some point you need to have someone who actually has — like this is the only way they can interact with the device take a look at that and give better feedback and say that, yes, this actually works. You would never take a fully done design for a website, for example, and say, yeah, well, I designed it myself, I know my colors and everything, yeah, no need to user test it.
So in goes the same for accessibility. And that’s it for me.
Thank you.

[Applause]

>> Thank you so much. Very, very interesting, I think. I guess there will be some questions for you in the audience.

>> Hi, so a very cool project. Do you find at any point that the feedback that you got from people with disabilities that ended up just making the design overall better, not just more accessibility, but better for everybody?
>> Yes, yes, I actually forgot to mention that. I think actually one thing was actually this bar at the top, which I think if you didn’t — if you would have countered it in your first scene of the thing, it was more — many sighted users thought those were buttons, so the first thing they would start to do is, oh, I don’t want this to be level one. I want this to be level four, or vice versa. No reason for super-security, so they would start pressing on these buttons. They looked like buttons to this person’s mind. And the thing was, when you used the assistive technology, it read it as saying, security level is this of this. So it actually presented the information a bit better. And I think that was — I mean, that was interesting in that, like, nobody who used Talk Back got caught up by that. And they never thought in their mind that, like, oh, this UI is only — or they were like, this UI is providing information to me, so I know what is going on. Whereas others thought, oh, this is providing me a way to configure my — you know, what is going on here. And they would think of using it that way. At least in that sense, yes. Color contrast, I didn’t go into it much here. It’s more in the paper. Some of the things were color contrast was definitely affected by how we did stuff here, size of text. Yeah, I think several things that we found made the overall design. I didn’t show the final UIshere. They were — yeah, they were completed for the project but never actually implemented, so we didn’t get to see those in real life.
>> More questions?

>> So I would like to know if you — how many users did you have involved in the evaluation? And also, did you have like multiple cycles with them for the requirements and the evaluation?

>> Yes. This is described a little more in the paper, of course. We did two iterations through the whole project, so we had two sort of evaluation iterations. I think — when we did the focus groups, I don’t think anyone in focus groups were necessarily involved in the final evaluations. No, probably one or two, because they were held a couple years earlier, and then the evaluations happened. For the evaluations, for the accessibility evaluation specifically, there were about — I think there were 12 or 13 for the VR evaluations. And for the evaluations, the real world evaluations you could say, there were about 22. Total there were about 99 for the — if we include the other countries. But they were, again, primarily targeting standard users. I don’t really like to use that word.
People who didn’t necessarily, like, have a disability that was the main reason they were in there for evaluating.
So something like that. But I think the numbers are more — I’m pretty sure I put the numbers in the final thing.

>> Anyone else?

>> Thank you for a great presentation. Actually, I think my questions have been answered, so I had to find another one, but I think — I do have one, actually. Because I think that you’re doing comparative studies, something I do myself, and I find it really difficult making these cross-cultural comparisons, so maybe you could elaborate a little bit about that. And I enjoyed seeing 99 people, but, I mean, if all the other countries have their different disabilities, what is the use, actually, to be honest? That’s a question I ask myself as well. So it’s not a criticism.
>> Yeah. How could I say — I don’t have all the stats in front of me. I mean, in general, most — it was a pretty — what we tried to do is get a pretty good mix of people in the different countries. So we tried to get sort of different education levels and things like that. And we tried to make sure that, for example, that no country had just students, for example. So there was a pretty wide age range for all the participants. The thing that we wanted to — that we actually wanted to enforce here, which was kind of this — we actually had to fight it a little bit in study design, was this idea, well, should we, like, exclude the people, you know, the accessibility ones, right? Because they have disabilities, right? So we should actually exclude them from the data set. And we thought, no, the whole point is to show this is a universally designed system, so really the person’s disability should not be a deciding factor in this. So actually we argued that, like, we shouldn’t have a variable that is actually describing the person’s disability. Because we felt that it was better to kind of see overall how that worked.
I would say that there were still some — still some fighting over that, but at least we got that through in the thing. But overall I think also the fact that we had people from Germany, Austria, and Norway, yes, there are cultural differences and I think we could say, for example, in Norway there was a much bigger sort of cultural thing to sort of trust things more than, like, you would find in Germany, at least according to the data we got. But overall, like the thing that was interesting was that, like, the user interface — people liked the user interface, or they understood what was going on and in that — that seemed to be standard throughout. So we felt that that was kind of something nice to get from that.

>> Thank you so much.
>> Thank you.

[Applause]

Note

Rough edited copy by AVA AB and Certec, LTH

Remote CART provided by: Alternative Communication Services, LLC (acscaptions.com)

This text is being provided in a rough draft format. Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.