Digital prototyping workshop at UXLibs conference

At the 2019 User Experience in Libraries (UXLibs) conference, themed from research to design, I led a digital prototyping workshop. The case for my workshop was to design an improved mobile experience of reserving a group study room. The aims were to empower participants with skills and confidence to:

  • build interactive digital prototypes quickly and easily from low fidelity paper sketches
  • test prototypes with users to gather feedback, iterate and implement improvements to digital experiences
Table Of Contents
Slide deck used in the workshop

Idea seed

The idea to improve the experience of reserving a group study room stemmed from seeing reservation QR codes on kiosks at Monash University Library. Scanning a QR code to reserve a room in the library system quickly leads to disappointment. SpringShare LibCal has yet to be designed for mobile, and presents serious accessibility and usability issues.

Insights

Group study room reservation software often gives a poor experience for mobile users.

Issues that are apparent when looking at LibCal on a mobile:

  • Unavailable slots are shown. Users can’t reserve these!
  • The first 17 rooms are visible but scrolling moves the date time headers off-screen.
  • The capacity of each room is truncated from display – it’s impossible to choose a big enough room.
The Color Blind Simulator shows what someone with Deuteranopia (1% of males) might see.

In addition, the colours differentiating available and unavailable reservation options lack contrast for those who have a colour vision impairment, especially types of red-green colour blindness.

Stories

A job story aims to supersede user stories by replacing assumptions with context.

Unlike user stories, a job story adds context (the When _ situation), and focuses on their motivation.

Story #1

When we need to do focus work this weekend
I want to reserve a group study room
so we can collaborate on our group project.

Story #2

When we need to cram for this afternoon’s exam
I want to reserve a group study room
so we can learn together.

Story #3

When our group (7) need to rehearse this evening
I want to reserve a group study room
so we can practice presenting.

Mobile context

Given the QR codes on Monash University Library kiosks, I added further context to each story, that users were using their mobile. Also, from a responsive design perspective, it is logical to start in a mobile context. It is easier to scale up from the narrowest constraint layout to a wider screen, rather than the other way around.

Problem statement

Framing these insights and contextual stories as a problem statement:

Mobile users struggle to find an available group study room in their desired time-frame.

How might we …

Then I used the following “How might we …” statement to generate an idea.

How might we make it easier for mobile users to reserve an available group study room in their desired time-frame?

Idea generation shortcut for a 1-hour workshop

I had to come up with shortcuts that would maximise participants’ time to focus on new skills. One shortcut I used was to skip idea generation, and provide a single, ready-made concept instead. This went better in the second running of the workshop, where I explained we lacked time to do both generate ideas and build a prototype. (Sorry this wasn’t clear to participants in the first running.)

Forming a concept

From ideas I formed a conceptual model that might answer this “How might we …” question. To determine whether my hypothesis is valid or invalid, I need a prototype and users to test it. The UXLibs conference was a perfect opportunity to broaden prototyping and testing efforts to a large number of libraries.

Concept to sketch

A successful concept must show relevant reservation options:

  • In the desired time-frame – users already have a time-frame in mind.
  • Only show available options – don’t show options that aren’t available.
  • Show options designed for mobile.
  1. Time-frame selection with checkboxes allowing selection of multiple options.
  2. List available times within chosen time-frames. I’ve shown examples with 1 hour duration, 2 hours, and a half hour – you might choose to use durations based on your business rules. The options also indicate room capacities at those times. Note the default date (Tue 18th) should be the earliest when an available time-slot exists. Also, where there are no available time-slots on a given day (Fri 21st), the day name and date is greyed out. Users can scroll ahead to the following week by using the right > button.
  3. List room capacity options for the selected time. If users select a time that only has a single capacity option, then this screen is skipped.

The concept addresses issues concentrated into one screen of LibCal. I used the one thing per page principle to spread the design to three screens. As well as being easier to design, one thing per page reduces cognitive load.

Sketching on a mobile template

I could’ve provided handouts with my 3 sketched screens but I feel asking participants to sketch by copying from my example slide worked better. It gave them ownership of the prototype they were about to build. To create 3 sketches for a flow, I organised participants into groups of 3 with only 1 screen for each participant to sketch.

Participants in my digital prototyping workshop begin sketching a screen design on a paper template.
Participants start sketching a screen on a sketch pad template to build their prototype.

Installing the Marvel app

Marvel app is one of many prototyping tools you can use to turn low-fidelity sketches into click-through prototypes in minutes. It was selected for the workshop as it has:

  • shallow learning curve
  • mobile apps and a web app for further functionality
  • freemium business model
  • easy to share and test

To help participants install the Marvel app, I showed a slide with separate bit.ly short links and QR codes pointing to Marvel for Android and iOS. Only a few participants managed to scan the QR code, and it was worth having some participants one step ahead.

Creating a Marvel project

Once participants had Marvel app installed, they were instructed to open it and:

  1. Create project
  2. Name the project: Test
  3. Choose your device
  4. Add some designs (tap +)
  5. Choose camera to scan your 3 sketches

Scanning the sketches

After scanning sketches, the ability to resize and crop means it doesn’t matter whether each group participant had a different size phone. I showed 0:26 to 0:39 of Paper Prototyping mit Apps to demonstrate the scanning process.

Linking screens

Three low fidelity sketches to be linked together to build a digital prototype.
Arrows indicating the flow we’re going to create by linking screens together.

Next I showed Paper Prototyping mit Apps 0:39 to 0:54 to demonstrate how to link screens into a flow, with step by step instructions on the following slide.

Step by step instructions for linking screens together to build a prototype.

With screen 1 linked to 2, and 2 to 3, now test it for yourself by pressing the “play” button. Some participants also linked the < Back button from screen 3 to 2.

My digital prototype

Testing your digital prototype with users

The point of creating a prototype is to test it with users. Thus qualitative, preferably moderated, usability testing will answer questions such as:

  • Can people use the product?
  • What ideas do users have to further improve the interaction?
  • Is the experience with the prototype measurably better than the existing interface and interaction flow? Metrics to compare could include satisfaction; time to complete the task; and a System Usability Score SUS) evaluation.

It’s also possible to A/B test a digital prototype against an alternative design. To avoid bias, match the fidelity of all variations. To see which design works better, A and B variations need to be comparable. For example, if your prototype is freehand paper sketches, then the alternative should also be paper sketches.

Question: digital prototyping fidelity

Should we ramp up the fidelity to crisp ruled lines, rounded button corners, etcetera? Low fidelity, rough sketches are excellent for garnering volumes of rich feedback. The opposite is also true. Hence users feel high fidelity prototypes are so polished that there’s little scope left to adjust anything. Use a level of fidelity relative to where your prototyping is in the design process. Invest in low fidelity prototypes early on. If needed, gradually increase fidelity in each iteration of your prototype, and expect more constrained feedback with increased polish.

Iterating to validation

After prototype testing with 3 to 5 users, we learn some answers to our questions around usability issues, and other user ideas. Incorporate feedback that will lead to a measurably better experience, into a subsequent prototype iteration and testing round. Then repeat iterating and testing your prototype until you have validated findings.

Validation to implementation

Share validated findings with your vendor / system developers. Your goal from here is to have a pilot developed (with real data and user testing) to see if an implementation will thrive in a production environment.

For example, SpringShare are very open to customer feedback, and more likely to develop a pilot for a reconceptualised LibCal when presented with several library’s test results.

While LibCal is popular, it is not the only system for reserving library rooms. Libraries using alternatives to LibCal could also collate valid results, present them to the vendor or in-house development team, and seek development of a pilot.

Wrap up

To sum up, while the case for my workshop was designing an improved mobile experience of reserving a group study room, prototyping and testing can and should be part of your design process. I found preparing for this 1-hour workshop a far greater challenge than preparing for lightning talks. Not only did I have to convey a hypothetical design problem from a digital flow that is relevant to libraries, but also to focus on rapid skill development for parts of design process that I suspected were absent. I hope attendees are now confident to:

  • build interactive digital prototypes quickly and easily from low fidelity paper sketches
  • test prototypes with users to gather feedback, iterate and implement improvements to digital experiences

Digital prototyping and testing are part of the design process

We can’t afford not to prototype.

Idea sources

Ideas for improving the room reservation experience, prototyping and testing came from:

References

Below are links to references cited in the workshop slides:

Input width to guide sighted users

I’ve created HTML and CSS code to illustrate an idea for setting the width on form fields where data entered has a known maxlength. My case is forms that ask for a postcode. In addition to guiding sighted users, I’ve added attributes to make completing on smartphones as easy as possible.

… you might be tempted to give every address field the same width.
But giving the postcode field the same width as every other field increases the cognitive effort needed to fill it out. This is because the width gives users a clue as to the length of the content it requires.

Silver, A. (2018). A Checkout Form. In Form Design Patterns. Smashing Media AG.

For example, Australian postcodes are 4 characters long. Setting the width of the input just a little wider than this helps sighted users understand what is expected.

See the Pen Input width to guide sighted users by Vernon Fowler (@vfowler) on CodePen.

HTML

My main reason for switching the input type away from type="number" to type="text" is I discovered the presence of spinner buttons causes painful experiences. In September 2018, manual accessibility testing a form postcode field with type="number" caused confusion with increment and decrement spinbox announcements, and frustration with operating the keyboard to enter the 4 digits. If in doubt, check Silver’s list of criteria for When to use the number input.

Adding autocomplete="postal-code" benefits everyone completing a form that requests personal data. Autocomplete can save time, eliminate typing or spelling errors, and make it easier to complete for anyone with cognitive or mobility impairments. In Exploring WCAG 2.1 — 1.3.5 Identify Input Purpose, Gibson’s video clearly demonstrates how form fields with autocomplete contrast those without. Lastly, using appropriate autocomplete attributes is a requirement for Level AA compliance with WCAG2.1.

Using pattern="[0-9]*" will validate that the input only contains digits 0 through 9. As Australian postcodes do not contain letters or any other characters, this seems warranted. It can also trigger the large numeric keypad on iOS, for an iPhone but not on iPad. To achieve a similar keypad on Android, add inputmode="numeric", however:

Update May 10th, 2019: With iOS 12.2 Apple appears to have introduced a bug where the numeric keyboards … no longer invoke the true “numeric” keyboard with the enlarged number keys (beyond the “tel” keyboard).

Touch Keyboard Types ‘Cheat Sheet’ by Baymard Institute

In the meantime, with inputmode="numeric" iOS 12.2 iPhone users will see the keyboard with keys 1 through 0 across the top row, with special characters below.

According to Grainer, autocorrect is on by default. I’ve set autocorrect="off" to avoid any dictionary lookup.

Postcodes in Australia are all 4 digits, but we’re allowing at least 3 digits for anyone forgetting a leading zero from postcodes such as 0800—0899. Thus the minlength="3" maxlength="4" attributes. (By the way, a leading zero is another reason input type="number" is unsuitable.)

CSS

I’ve created style rules for any input that has a maxlength attribute. I set padding vertically and horizontally via padding: 0.3rem 1ch; because, as McDowell concludes, “rems are good for vertical cadence, and ch is good for horizontal cadence” (Using Ch, An Underappreciated CSS Length by Justin McDowell). I also use the ch unit to calculate the input box width. Before going further, note that:

… a ch unit is equal to the width of the 0 (zero) glyph found in the font used to render it. This definition works for monospaced fonts (where every glyph shares an identical width), but it’s completely unreliable for proportional fonts.

Making Sense of Ch Units by John D. Jameson

Rather than do extra calculations to use proportional fonts, I’ve chosen monospace fonts to help users distinguish a 1 from an l, or a 0 from an O, and any other similar looking characters. Try entering 1lO0 in the input box above to see how the characters render visually with these fonts.

Finally, with Australian postcodes at 4 characters, I set the width of the input box: input[maxlength="4"] {
width: calc(4ch + 2ch + 1ch + 2px);
/* maxlength + padding + breathing space + border */
}
I add 1ch of breathing space on McDowell’s formula. I found his fudge factor of 0.1ch put the blinking cursor hard up against the right edge of the input box. Sometimes the leftmost of my 4 characters had their left edge cropped. There was also the question: Had I typed more characters and these are the most recent 4? Don’t make me think. Adding 1ch of breathing space makes it clear that the input box has enough characters, and not more than the maximum.

References

From research to design: iterating a form wizard 🧙

Below is a written version of my lightning talk given at the A11y Bytes event in Melbourne on Global Accessibility Awareness Day, 16 May 2019. This follow-up lightning talk demonstrates how we overcame technical and non-technical issues to make a member registration process more inclusive.

In September 2018, manual accessibility testing revealed significant barriers to completing a high demand multi-step form. I thank Jamie Kelly, who first tested our registration form wizard in September last year. Pictured below in our follow-up validation testing in February 2019, he’s sitting at a table with his laptop open and an external keyboard. Jamie is blind, has a great sense of humour, and makes an excellent tester with amazing think-out-loud skills.

I also thank Troy Rasiah, our brilliant developer and database guru, collaborating with me throughout this project. Over five months, we made seven iterations, and resolved 5 of the 7 issues identified from Jamie’s initial session.

Table Of Contents

Outline

  • Form wizard designs
  • Manual accessibility testing scenarios
  • Issues identified
  • How we addressed (some) issues
  • Next steps

Form wizard designs

We actually have two form wizard designs:

  • One design for onsite kiosks attached to cabinetry. The onsite kiosks aren’t intended for screen reader use.
  • Branching from that is a design for all other devices (my photo here shows Jamie operating this form on his iPhone via a Bluetooth keyboard). It’s this design for other devices that we’ve been testing and iterating.

Manual accessibility testing scenarios

Our testing consisted of one task, to become a member, with two scenarios:

  1. Using a laptop, Firefox, JAWS, and email to receive membership.
  2. Using an iPhone, Safari, VoiceOver, and SMS to receive membership.

Seven issues identified

We identified seven issues. In order of severity, they are:

  • Imperceptible validation errors;
  • A mismatch from our conceptual model to the user’s mental model;
  • Spinners on postcode input;
  • An <article> tag announced on every step of the <form>;
  • A driver’s licence was the only example document as proof of address;
  • A <label> lacks a phone format example;
  • A link to a modal.

Read on for how we approached the first five of the identified issues.

Imperceptible validation

On his laptop at step 1 of the form, Jamie gave both a mobile number and email address. After pressing Next, validation errors are displayed in red text on the page but the screen reader is silent.

We need the screen reader to announce the validation, so we:
– Inserted the error text within the <label>;
– Set the focus to the first input with an error.
This required updating the jQuery framework that handles validation.

<button>s weren’t matching

A mismatch of conceptual model to user’s mental models can’t be picked up by automated testing. A pattern we had used in our form wizard was a few <button> elements for users to indicate a choice and to take them to the logical next step.
– It appears neat & efficient – it works on our kiosks.
– It has perfectly valid mark-up.

Wizard step 2 asks users to choose their preferred contact for membership delivery. A screen reader announces: “We’ll send your library membership details to your preferred contact”, followed by two <button> elements.

The last thing Jamie commented was, “I would have thought neither would be selected and you’d have to select one.” The <button> elements make sense for kiosk design, but through a screen reader the final words “…select button” exacerbates the confusion. Even if we accessibly hid the word SELECT, we still had the conceptual model of <button> elements: a mismatch to our user’s mental model. To address this, we had to replace the buttons.

Switching to radio inputs, and adding an explicit Next button was the easy bit. The hard bit was making the choice of options mandatory in an accessible way. Thanks Russ Weakley and Allison Ravenhall who contributed to our solution: using aria-describedby to have both a hint and validation message associated with the <fieldset>. When Jamie tested this in February, it perfectly matched his mental model.

Spinners on postcode input

Our old form design used input type=“number” for entering an Australian postcode. This makes it easy for Android and iOS but on desktop devices, it presents spinbox controls. Visual users might ignore these stepper buttons, but it confused our blind participant and exploded the time to complete this field.

Adam Silver wrote a blog post, When to use the number input, explaining the most inclusive way to capture numeric codes is to use an input type="text" with a pattern="[0-9]*" attribute. This removes the spinners both visually and to screen readers. Additionally, some smartphones will render a chunky number-pad for easy entry.

<article> on a <form>

An <article> tag was left over from an early page template. Screen readers announce “article” and that’s just confusing when heard on each step of a form wizard. We removed HTML5 article elements from the templates.

Driver’s licence … ineligible

To obtain an additional member privilege, we need proof that you live in Victoria. The only example document we listed was a driver’s licence. Blind people are ineligible for such things.

Although we’ve added utility bill as a second example, this doesn’t really resolve the issue for Jamie who pays his bills electronically. Our alternative of receiving a letter by mail also relies on a third party. By adding a second example, we’ve resolved this issue, but not yet for everyone.

Next steps

To reduce the remediation efforts needed in future, and have better designs out of the box, some next steps I’m taking include:

Photo by Ant Rozetsky on Unsplash

Testing with blind people is great for uncovering issues like mismatched mental models and any keyboard operation issues too. Things we won’t learn from blind users are issues such as low contrast, text too small, confusing visual hierarchies and spacing issues with touch targets. Broadening our testing pool to include low-vision and mobile users should help us learn how to design better interfaces.

Removed HTML5 article tags from a form

During manual accessibility testing of a form wizard in September 2018, an <article> tag was announced by the screen reader. This confused our participant each time it was announced on every step of the form! Sorry Jamie.

Video queued up at 7 minutes 52 where <article> tag announcement causes confusion and irritation.

Prioritising problems

Using the three question decision tree described in How to prioritise usability problems, I was able to classify this issue as medium severity.

Three questions in a process diagram to define four severity levels of usability problems
  1. The <article> tag announcement wasn’t during a critical or frequent (sub-) task, so it’s not on a red route.
  2. The announcement was not difficult for users to overcome. In virtual/browse mode the screen reader intercepts presses of “the up/down keys [to] move focus to the previous/next line”. (Quote from Léonie Watson on Understanding screen reader interaction modes.)
  3. The <article> tag was announced on every step, before pre-amble text or any form field. Because this issue occurred persistently throughout the wizard, I rated it as a medium severity.

Dr David Travis says we should interpret a medium severity problem as one that “will make some customers feel frustrated or irritated but will not affect task completion.” The video from our test session above illustrates minor confusion on the first occurrence leading to irritation after repeated occurrences on every subsequent step of the form wizard.

Must do manual testing to learn

It was a trivial code fix in the template, a task resolved in our late-November deploy. How did an <article> tag get in our <form> wizard in the first place? Back in February this year I worked with our developer to introduce HTML5 to improve completing the form on mobile devices. Still we can’t pinpoint how an <article> element found it’s way into the templates. I have not discovered an automated testing tool that would’ve alerted us to the presence of this undesirable combination. Again I find myself highly recommending The Importance Of Manual Accessibility Testing. Without manual testing, we wouldn’t have learned about this and many other issues that harm accessibility of web forms.

Accessibility testing a multi-channel form wizard

I gave a lightning talk as part of World Interaction Design Day #IxDD at the Melbourne Web Accessibility and Inclusive Design meetup in September 2018.

Slides from my lightning talk on lessons learnt from our pre-launch test of a multi-channel form wizard.

From plastic cards to form wizard

Before September 2018, Become a Library member was a single page web form that dumped everyone’s input into a holding bay in a database. Shifting from plastic member cards to digital distribution methods meant business process re-engineering and converting the single page form into a multi-step wizard.

Bring in the wizard

“a powerful design pattern … to simplify complex processes performed infrequently or by novice users.”

Wizards: Definition and Design Recommendations by Raluca Budiu on June 25, 2017 https://www.nngroup.com/articles/wizards/

Manual accessibility testing

In September 2018 I conducted manual accessibility testing on the first iteration of form wizard and the new self-service join processes. My colleague Janet Austin assisted with the session. Jamie Kelly, a blind person from the Vision Australia Library, was our participant. He tested two scenarios:

  1. laptop + Firefox + JAWS screen reader → email membership delivery;
  2. iPhone + Safari + VoiceOver → SMS membership delivery.

Imperceptible validation

I was shocked that the first show-stopper issue occurred in the first step of the form wizard. A validation message for Australian mobile number that appears visually in red text, wasn’t announced by the screen reader. Without assistance, it was impossible for our screen reader user to discover why the form was stuck on step 1, let alone recover from the error.

A validation error is visible but not announced by screen reader.

Progress for all

It’s vital to show your progress, to “distinguish the current step, and how many steps there are left.”

Wizard Design Pattern by Nick Babich on April 8, 2017 https://uxplanet.org/wizard-design-pattern-8c86e14f2a38
Our visual 5 step progress bar for sighted users.

We need to provide a sense of progress to screen reader users too. Unfortunately the HTML5 progress bar is not accessible! Scott O’Hara suggests “treat[ing] the progress bar as a visual decoration, hide it from screen readers, and provide visually hidden text as a means to consistently convey the information.” We use the Bootstrap .sr-only class to hide text on all devices except screen readers.

HTML and CSS for screen reader only progress indicator

Our participant heard and understood they were making progress. ☺️ The page title was announced as “Library member registration | Step 2 | State Library of Victoria” and this was reinforced by hearing “Progress: 40%”.

Buttons ≠ mental model of radio inputs

At step 2 of the wizard, users must explicitly choose their preferred method for receiving their membership: SMS or email. Their contact details are displayed with each option so they can check their mobile number or email address for correctness.

Two options coded as <button> elements did not match the user’s mental models.
<button type="submit" name="confirm" value="sms"> <button type="submit" name="confirm" value="email">

These buttons were the only form controls on step 2. Clicking one of the buttons would indicate your preference, SMS or email, and submit the form to step 3. These buttons completely baffled our participant. We’d been so focused on making easy interactions with large touch targets for the new kiosk devices, that we lost sight of underlying semantics (or lack thereof) and accessible form design patterns.

Our participant pointed out that the buttons really should be radio inputs. Exacerbating the mismatch of conceptual to mental model, is that step 2 lacked an explicit Next button. The design didn’t align with their mental models of interfaces or flow!

An inclusive design solution for radio inputs

Two days before our testing session, Hui Jing Chen posted Customize Radio Buttons without Compromising Accessibility, an inclusive design solution that makes radio inputs work for screen reader and touch screen users alike.

Log issues and iterate

Lastly, I recommend Eric Bailey’s advice in The Importance Of Manual Accessibility Testing: log issues you’ve identified. Also rate identified issues in terms of user value and team effort, to prioritise which changes to iterate in your upcoming sprints. For our next iterations of the form wizard, we’ll work on fixing form semantics and validation issues.

See the thread at https://twitter.com/vfowler/status/1044468802786922497 for links to references cited.