Aaaaarrrghhhhhhhh!!!!

Owen Davies
13 min readAug 14, 2016

--

That’s the sound of frustration. It’s a sound we hear a lot — especially when it comes to using new technology.

Millions of us now have access to the latest tablet, computer and smart phone. Most use the devices without issue or trepidation, but some users experience difficulty in the operation of such devices. Difficulties that mean they are reluctant to use them and are at risk of becoming digitally excluded.

It is not a solitary demographic that suffers from such issues, although there are some parts of society that suffer more anxiety in using technology. The older population for example has not enjoyed the immersion in technology that younger generations have enjoyed, so are more likely to have these anxieties. This is not to say that there aren't older users of technology. I'm sure somewhere right now, there is an octogenarian or two running about catching Pokémon. There are lots of people however, both old and young, who struggle to engage with technology or have limited experience and exposure to these devices who find them plain difficult to use.

For the last 12 months I've been learning all about user interface design and for the final project we were asked to select a project that we could use to demonstrate the skills we've learnt over the duration of the course.

I chose the theme ‘Glance’ for my final project. The brief was to show users the most salient information in an interface — to allow people to navigate through the noise. Interviews and observations of users I had undertaken highlighted how much of an issues this was. As a confident user of technology and someone who’s surrounded by it as part of their day to day life, I had not picked up how problematic this was for an awful lot of people. The brief asked us to navigate through the noise. But what if I could eliminate it? Or at least as much of it as possible.

I decided on simplicity as a point of view. That complexity does not equal functionality — this was an extension of that point of view and I set about undertaking the tasks needed to design a new operating system which I would prototype on a smart phone in the weeks to come.

Designing any new interface is a difficult task. Companies like Microsoft, Apple and Facebook spend millions of dollars each year refining the user experience and we know from high profile flops like Windows Vista that these companies often misinterpret the technological Zeitgeist or fail to convince users that their new product offers an advantage over the old that is worthy of the overhead of learning all about how to use it. From the very beginning, I was a little unsure about whether or not I had bitten off more than I could chew, but in the spirit science, I decided to push on anyway.

But where does one start? Well a good way to get going is to determine the needs of the user. Interview and Observe. Look at research. Check out the competition. Browse the internet to come up with ideas that are analogous to the problems and issues that your users experience. Are there any parallels? Can we draw inspiration from other areas of life? These are all valid ways to explore.

Observation that people used technology in very different ways and had differing levels of comfort using it.

Once I had captured our users needs I could begin on the design process. Pushing any preconceived ideas out of your head is a good way to start with the design process. We need to concentrate as designers on the real problems that users face, not just the solutions inside your head. It’s also not a good idea to dive straight in to designing on a computer at this stage because you could get carried away with the minutiae, rather on what you should be working on at this stage is finding solutions to the problems you uncovered in the need-finding stage.

A good way to do this is using storyboards (and co-incidentally one of my favourite). By working on low-fi paper visualisations we can knock out lots of ideas quickly, with little, or few resources and we can get input from everyone involved in the design process, not just hackers and illustrator experts. Oh and it means that I can get to doodle. Something I enjoyed doing on my school exercise books all those years ago and still do in those less than interesting meetings today — ahem.

An Example of a Storyboard for the MyOS Operating System

So okay, now I’m getting somewhere. I can now start to brainstorm some more ideas. In fact I’m running through multiple iterations of ideas. For this process I involved a group of willing volunteers who could all help me come up with some of the ideas and could also critique and point out some of the problems with those ideas or indeed the solutions to those problems and start to shape how the final product would look and feel.

In order to be more efficient, even though my idea was to span the product across any computerised device. I chose to use a mobile device as the platform to prototype the solution on. I did this for a number of different reasons. First is that more and more people now act with this type of interface through a smart phone. Second is that more and more people now buy tablet computers and indeed the demographic that we are trying to market the product to is likely to look for the easiest solution and tablets win that battle and lastly and most pertinently perhaps is that this is the medium we were asked to design for.

At this stage I’m still on paper — doodling away to my heart’s content. But now I have an added problem. I need to be able to test the functionality we’ve come up with. On paper!

Cue lots more doodling, and cutting out buttons, menus and graphics for the next step in our process — the paper prototype and functional walk-through. I’m interested here in how people try and interact with life-size representations of my design. I want to see where they try to tap, scroll and type and where they got lost or struggle interpreting the design. This is sometimes quite a difficult thing to do. We have to choose someone who has the imagination to look past the fact that they are pressing and swiping bits of paper but we want also to choose someone from the demographic we are aiming to market our product to as well as someone who is comfortable with using my competitors products. It would be great to design something that the less technologically able could use, but not by confusing the more able user and thereby excluding them instead!

Paper prototyping — No Computer in sight

Once I’d done enough testing and was satisfied with how my prototype functions — or if not, made a list of changes and re-tested these, I moved on to the next stage, the first digital mock-up of the prototype.

This was not a chance to get the Photoshop skills out. Not quite yet. We want to test the functionality of the prototype here, not the design, so it should really be a low fidelity wireframe representation of the system not a fully polished visual masterpiece.

A wireframe of the home screen. Notice how two of the buttons from the paper prototype have gone.

We can now move on to a more formal way of testing and for this I was about to go global in my quest as a designer for the first time. Hooking up in a truly international gathering of minds from across the globe (UK, Mexico and Sweden to be exact). What we were doing was undertaking a task known as Heuristic Evaluation or HE for short. This method, developed by Jakob Nielsen in the early 1990’s using a set of criteria — Heuristics, that a user interface should not violate. Our task was to evaluate each other’s prototypes for heuristic violations which we could address in our prototpes before moving on to the next stage.

Heuristic Evaluation

Using other designers to critique your own work is always really nerve wracking and I’m glad that Juan and Silvia were not too disparaging of my work. Thanks guys!

So armed with yet another list of things to change, I set about improving the design and functionality of the system. At this time I also started to ‘flesh out’ the design, but making it more appealing, visual and akin to how the final product would look. Whilst not strictly necessary at this stage, I figured I would get better results in the next part of the project if I made it look as it would in real life.

Is sharing my project with a couple of other interaction design students was nerve wracking, the next project was a nail biting extravaganza. It was the first push of the product out into the big bad world.

OK so it was actually the not-so-bad world of getting friends, family and colleagues test the prototype, but it was still a real live person using my system.

Real life testing in justinmind,com

It’s always a bit disheartening to find that some people were still having problems using the interface. With some of my testers (this time I purposely chose people who were self-described technophobes) struggling,I had to re-think the solution. It seemed that once past the first page, they could follow the text based menus that followed pretty well. I decided I needed to rethink the home screen.

It seemed that my original idea for a menu of things people could do “I want to” such as send a message, go-online etc and a menu of things people could see “Show me”, my schedule, my email etc was not as straight forward as it first seemed all those weeks ago. Indeed when I re-thought it through myself, it did sometimes seems a little ambiguous and maybe a little over-thought.

I decided on a new single button design to replace the original two button concept , but would it make a difference?

Old two button and new single button design with instructive test.

So how would I find out? Thankfully the course tutors had provided the solution in the form of usertesting.com where we would get to test our different interface prototypes with real people who could test the different versions and provide valuable data and feedback about the two different prototypes.

I designed a script that would allow the testers to walk through the prototype and undertake a number of identical tasks that could be undertake on either prototype. Remember in the beginning I said I might have bitten off more than I could chew? Well operating systems — even simple ones — should be able to complete an awful number of different things. Gulp!

So whereas I’d seen other prototypes with 10 maybe 12 screens. I had over 35 by the time I was ready to test. Even then there wasn’t any functionality outside the tasks I’d ask my testers to complete. Nevertheless, the deadline was fast approaching and the test posted just before I retired to bed.

So the next day was my day for writing things up. Luckily it was a Saturday so I could start early. Or so I thought.

I watched as my first tester was presented a log on page. Not for my prototype (which ironically was the first task), but for the prototyping tool. I watched as the user tried repeatedly to put a fictitious username and password into a real system. “Oh well”, I thought, “The next one must be better?”

Nope. They were all the same. All were presented with the same log-in screen so were not able to undertake the tasks. What had happened? It worked fine when I did a run through. Not once, but twice, in two different browsers to make sure it functioned well in each.

What I hadn’t figured out was that I was still logged in to the prototyping tool and that it would let me hyperlink to the prototype with no problem. It was my prototype after all. I guess now the little switch in justinmind.com that said:

…should have started to ring the alarm bells in my head. But at about 20 minutes past midnight after working on the prototype for a few hours and in dire need to lie prostrate in a state of slumber it kind of passed me by.

Ah...

Take two. This time with the switch firmly in the:

…position, I tried again.

This time. Success! I had four viable videos of users testing each prototype. I had designed a number of different tasks, each with a different mode of data collection. The one I was most interested in however was the difference in time it took for users to complete the second task. This was the first time they would encounter the home screen.

Would it be any different?

In a word…no. The difference in times was minimal between the two test subjects. If anything I was disappointed, but I shouldn’t have been. the tests were actually quite successful. The users managed to complete the tasks pretty well and actually gave some good feedback on the project. Oh and I had even more things to add to the ever growing list of things to do. I needed to add an indicator that showed the user there were items off screen that needed to be scrolled for, some more bug fixes and a permanent help link. This was something that was called for in a previous test, but I hadn’t yet gotten around to adding. This additional test reinforced the need to add one.

A/B Testing

So here we are. After almost a year studying the art of interaction design and another ten weeks on the final project, my project is done.

Well not quite. Even though the results from the online A/B test were similar, I wanted to test a bigger population, so I set about setting up my own test lab where we asked 30 users to undertake the same A/B test as we conducted on-line. This time I recorded the time to undertake all tasks that started from the home page and averaged the results per user. Each user was chosen randomly from the initial test population. We had 23 people whose data we could use to see if there actually were a difference in the two designs. And yes…

…I was still proved wrong. Our analysis of variance still showed no statistically significant difference in the average times for each prototype. Oh well, so much for hunches.

Box plot of average time taken to complete tasks in two different prototypes.

And now, we really are at the end. Or is it the beginning. For this year long quest has awoken something inside of me. I’d left all thoughts of formal study behind me some years ago — surely work was the important thing at my time in life (lets just say I’m older than 35 to keep my modesty) ? But now, I’ve learned so much and don’t want to stop now.

To the next project….and beyond!

The MyOS logo

The prototype:

Click Here

The launch Video:

Click Here

Epilogue:

Thanks for taking the time to read this. It’s a little long I know, but I have an unfortunate affliction that makes me witter on aimlessly for long periods of time. I hope you enjoyed the above. I thought I might put down a few things about the whole process that caught my attention, or just hurt my brain.

Firstly, did I achieve what I set out to? Well no, but I’m not really concerned and in fact I’d be a little less than honest if I said I could design an entire operating system in 10 weeks. But it was a proof of concept and I really wanted to try and stretch myself. Did I have fun. Yes, although it was really hard work sometimes, trying to juggle everything to get the work done.

What did I learn? First and foremost. It’s not easy, although I saw lots of people with great ideas and some fantastic designs. I also met some really good people, all of whom were passionate about HCI and who were undertaking the course for a whole number of different reasons. Am I going to follow up with more study? At this moment in time I don’t know. Study is expensive and I’m not sure I have the years left to justify a big expense at the moment. Will I follow up with a delve into more literature about the subject. You bet.

What did I struggle with? Well I’m no statistician even though I work with data and huge datasets every day ha-ha. I have to admit I had the same kind of fear I had in my undergrad days from trying to wrap my head around some of those calculations, but I got through them okay in the end.

Cheers! And thanks again!

Owen.

--

--

Owen Davies

Information Manager in Local Government. I like thinking about UI/UX, beer and most things furry.