2.3. Design to prototype

Published January 8, 2018

Learning Objectives

This blog post sets out with others to meet the following learning objective:

Table 1. Learning objective 3
Learning Objective 3
Blog post(s) and associated artefacts describing and demonstrating:

  • the iterative design process from early paper prototypes to final digital wireframes;
  • how interaction design principles and patterns were applied to the interactive prototype(s) produced.

Design concept

During our December workshop, we explored improving the experience of making a shopping list and then transferring it into the shopping app. (see Figure 1). We wanted to bring the list making into the app and enable device sensors to accelerated the process.

wipeboard sketch
Karen’s sketch of a sensory search (in this case, “Hey, Tesco”) to create an arbritary list and then to identify concrete items from it

Tesco list making

The Tesco desktop platform enables users to list arbitrary items in their Multisearch feature (Figures 2 and 3). On Go, users click on each item to initiate search results. This is a sensible solution to searching over 30,000 product lines.

screen grab from Tesco desktop grocery shopping platform
Figure 2. The Tesco desktop grocery shopping platform “Multisearch”
GIF animation of the Tesco desktop grocery platform Multisearch interaction
Figure 3. Detailing the search list building

Multisearch in the mobile app

It is possible that, if Tesco had designed their platform as mobile first, a mobile solution would already exist.

Investigating a solution

When wireframing concepts, I found transferring Multisearch to the mobile environment was constrained by real estate (see Figure 4). The experience may not be as positive.

screen grab of a local wireframe
Figure 4. Wireframe of the Multisearch in a mobile viewport

Incremental search pattern

Multisearch results appear quickly on the desktop platform. This suggests opportunity for an incremental or auto-suggest search pattern initiated on key-up when typing in the Search text box.

You can open an early Axure wireframe of the list concept in your browser. Search for Apple or Banana (see Figure 5.)

a list
Figure 5. Early iteration on which to frame discussions on lists and allied concepts in Axure


Our team were keen to leverage mobile device technology and software to ease search tasks using typical sensors including:

  • Text entry
  • Speech recognition
  • Bar code and QR code scanning
  • Image recognition using the camera

These extend the accessibility and utility of the search task and may add delight?

Accessibility and presentation

For accessibility, the search features are semantically positioned in the HTML according to their useable order in assistive browsing technologies: aural, text, and then vision. CSS can arrange the buttons to art direction. In this case, we present the buttons to a universal experience. (Figure 6).

screen grab of the search box design
Figure 6. Outlining the multi-modal search box interaction design

In testing, orientation to the controls appeared natural. We determined that a simple user performance support may assist less expert digital users. (See Figure 7. UX text to be confirmed.)

Screen grab of the basket page
Figure 7. A gentle user performance support strategy on the Basket page.

Figure 8 lists the considerations of the search interaction designs.

Figure 8. Multi-modal search box interaction design.

NOTE: Although discussed in the following sections, sensor error handling is not included in the prototype.

Voice recognition

Voice recognition search is available across many platforms and systems. As it requires access to the microphone, it is only emulated in the prototype.

Text input

Popular search form patterns execute with a submit button. The button function is signaled with a magnifying glass icon.

Text input can also control system actions. For example, on key-up. Using an incremental search pattern negates the need for a submit button, The label signals the form’s function. This negates needing a Search icon. (Figure 9).

GIF animation of the search feature and results
Figure 9.GIF animation of prototype’s type-to-search feature

Error handling covers:

  • App access to the system microphone
  • Unrecognised speech snippet

Image capture

Karen promoted an image recognition feature demonstrated on an Android device. The user points the camera, takes a snapshot, and gestures over the image to prompt an image search. The system returns results and shopping suggestions.

Including real-time access to the device camera requires specialist code and the right development environment so we can only simulate:

  • Selecting the image recognition feature
  • Lifting the phone camera to an object
  • The system recording and parsing the image
  • The system returning results

Error handling

  • App access to the system camera
  • Unrecognised image

Barcode and QR code scanning

Barcode scanning is included in the existing app. As it requires access and control of the camera, it is only emulated in the prototype. See Figure 9

Error handling:

  • App access to the system camera
  • Unrecognised code

User testing the technologies

Accessible architecture

I wireframed an accessible HTML architecture to prove the concept using a content-first approach. (See Figure 10).

Figure 10. Wireframing an accessible HTML search interaction

Using CSS classes, we can wireframe hiding copy texts from the visual presentation without hiding them from alternative browsing technologies. (See Figures 11 and 12.)

screen grab of an html wireframe of the search interaction
Figure 11. The HTML wireframe presented without CSS (above) and with light CSS applied (below).
screen grab of raw HTML used to wireframe the search interaction
Figure 12. The basic search interaction HTML providing facilities for visual styling with CSS

Handling unknown products

The Tesco desktop grocery shopping platform fails to process unknown inputs. Our user may want to add arbitrary text strings their list. It’s their list, after all.

We can enable our users to input any text string as a list item and mark it, “unlisted”. This feature could make the list useful to a whole shopping experience and opportune allied services. (Figure 13).

The strategy could also manage input errors without roadblocking our users’ list making activity.

screen grab from a wireframe
Figure 13a. Inputting an unrecognised text string
screen grab from a wireframe
Figure 13b. Accepting an unrecognised item into our user’s list

Product Selection

We have challenged the popular shopping flow of search, list results, add to basket by placing Search and result inside the basket. And we have added a quality feature to select whether fresh products should be:

  • Ready to eat, or
  • Ripen at home

This selection cannot easily fit into the typical result tile (Figure 14). Our solution is to move the order configuration tasks (typically a quantity selection and Add to Basket button) in to a tabbed dialogue with access to mandatory nutritional, allergy, and promotional information. It replicates our real-World store shopper behaviours when evaluating products.

design elements of the app search results tile
Figure 14. Tile design elements

To scroll, or not to scroll results?

Scrolling of large search results is discussed in Figure 15. There are strategies to choose and which we have not fiallised in the scope of this student project.

Figure 15. Scrolling or paginating results

Designers may borrow others’ beliefs that scrolling and pagination are bad, or that our users cannot process volumes of content or choice. They will censor search results to protect their users from excess cognitive and motor loads.

Here’s a problem – it’s a supermarket! Don’t customers demand choice and the enterprise wants to sell?

UX Magazine report Apple’s removal of the scrollbar from browsers: not because our users don’t scroll, but because they know when and how to. Research by the Nielson Normon Group (Fessenden, 2018) suggests that our users will scroll and may not scroll beyond the third page equivalent length.

This does not mean we only serve three pages. It means we surface the most relevant (or sponsored) data in that space and leave our users the choice to scroll further. Our user chooses how many and how quickly they scan results and whether to refine or filter their search criteria or to accept a reduced choice from the top “three pages”.

Conversely, shoppers are reported in The Telegraph to be overwhelmed by choice (Henry, 2015) and to buy less. (Find similar articles with Google). And how much choice is offered is an enterprise decision based on their economics of choice (Nipun, n.d.). And we must anticipate that Tesco has already managed the economics of choice in their product offer of over 30,000 products.

Our users’ memory uses in search and retrieve cases is discussed briefly by Preece, Rogers, Sharp, (2015, pp. 74-75) where they touch upon retention and limits of working memory (the classic, seven plus or minus two).

In Learning Design these limits are managed by clumping information in meaningful ontologies or catagories, or by easing the cognitive process using recall and recognition. The product photography displayed in results will aid recall, prompt our users to catagorise and discern groups of results through the process of recognition: exploiting prior learning and familiarity. A picture paints a thousand words – if we let it. The images must be meaningful and clear.

Cooper, Reimann, Cronin, Noessel, (2014, pp.546-548) briefly touch on search strategies designers may evaluate to mitigate our users’ dissatisfaction and Hoober & Berkman, (2011) provide useful discussion on design patterns to contain them.

As UX designers, we must take responsibility for the meta-data large data sets require designed to enable effective search. We should not hide poor information design by controlling our users’ access to the data they and our enterprise want offered in context.

As always, it depends. (Test!)


Basket contents listing follows Material design guidelines.

I wanted to implement a (Material) swipe-to-delete feature, which my team colleagues had reason to resist in favour of a trash can icon (Delete button) and a system confirmation alert. The swipe-to-delete advantages the confirmation strategy in one or two gestures. It is efficient and removes clutter.

On the other hand, without testing real users the trash can is advised for its universal recognition.

User testing

In user testing, we found our participants did not like to list products twice: search, add, and then configure. That prototype separated the experience of building the list and then adding it to the basket. (See Figure 16.)

srceen grab of iteration one
Figure 16 . Iteration One’s flow of search, pick and list, then configure. (From the prototype produced for us by Mary).

Iteration Two

In our revised solution (see Figures 17 and 18), we have integrated the actions into one flow:

  1. Search
  2. Pick
  3. Confirm and configure
  4. Review

And all in the basket page. And our users choose to just shop, set up collection, or order a delivery when they choose; before, during, or after filling their basket.

A paper sketched flow diagram
Figure 17. Sketching the newly agreed flow on close of our classroom meeting
Screen grab of new flow
Figure 18. Using an Adobe XD click-thru to confirm the flow with the team

Mary wireframed the newly agreed flow in Sketch with Karen’s input (see Figure 19.) to guide my Axure re-work (see Figure 20.) Product image treatments were not possible as I was loading Tesco images and creating a new fleet of 50+ would take too much time.

screen grab of a wireframe
Figure 19. Mary’s wireframe of the newly agreed flow delivered in Sketch
screen grab of wireframe
Figure 20. refining the wireframe the search, pick, configure, and add flow in Adobe XD

Delivery, Collection, and Shopping

The Tesco-preferred flow is to book a delivery or collection before creating a basket. A future Save Basket feature will enable our users to update to any saved basket before booking delivery or collection.

Mary wireframed the ‘date-picker’ and I set up Axure to enable the display of today’s date (in January) and place the counter on the correct day. (See Figure 21.) Data driven details like this help suspend disbelief during our prototype testing and enable participants to more closely experience our design.

GIF of date picker interaction
Figure 21.GIF animation of the date picker wireframed by Mary and prototyped with date data by me.


There were one or two interesting observations regarding UI and interaction design ‘standards’ summarised at Figure 20.

Figure 20. Standard arguments

We decided to use Material design as a basis for our prototype’s presentation. Although art direction was not a factor at this stage, Material offers a clarity that presents wireframes well.

And whenever implementing a “standard”, there will be arguments. It is my understanding that there is no Standard unless our enterprise creates one. We experienced moments where “standards” were applied from belief or preference.

OK and Cancel

Mary noted that I swapped OK and Cancel from her wireframe I was working to. I agreed to return the buttons back observing there is no Material standard button layout, e.g. Material Design in XAML uses OK-Cancel. Nielson (2008) provides the choice is a matter of design.

In the words of Bowels and Box (2011),

“There’s no guarantee that a solution is right just because it’s on a famous website.”

Bottom navigation bars and menu buttons

We placed a draft navigation bar at the bottom of the page. As part of placeholder content, I inserted a ‘Kebab” menu button in it, which was challenged for not being “standard” by Karen.

I’m familiar with Material design guidelines and shared the link to the Material Design, App bars: bottom page illustrating a “Kebab” menu button in the bottom navigation bar of a Material Design “standard”.

cartoon of designers disagreeing over standards
Cartoon by the author (aka. dieUX, Tap27)


Large organisations such as Google and Apple have invested in user research to develop and prove their patterns. That doesn’t mean the patterns are right for our own users. We should still user test them.

User Experience Designers are right to apply popular standards and should appreciate that there are no standards. Only guidelines unless directed to use them by our enterprise and as standard. A little research goes a long way too.


Bowles, C., and Box, J. (2011). Undercover User Experience Design. Berkley, CA, USA: New Riders.

Cooper, A., Reimann, R., Cronin, C., and Noessel, C. (2014). About Face, The essentials of interaction design. Indianapolis, IN, USA: John Wiley & Sons.

Fessingdon, T., (April 15, 2018). Scrolling and Attention. Nielson Normaon Group. Retrieved January 20, 2019 from, https://www.nngroup.com/articles/scrolling-and-attention/

Henry, D., (October 21, 2015). Help! There’s too much choice in the supermarket (and it’s all mediocre anyway). The Telegraph. Retrieved January 20, 2019 from, https://www.telegraph.co.uk/food-and-drink/features/help-theres-too-much-choice-in-the-supermarket/

Hoober, S. and Berkman, E. (2011). Designing Mobile Interfaces: Patterns for interaction design. Sebastopol, CA, USA: O’Reilly Media.

Nielson, J., (May 27, 2008). OK-Cancel or Cancel-OK? The Trouble With Buttons. Nielson Norman Group. Retrieved January 13, 2019 from https://www.nngroup.com/articles/ok-cancel-or-cancel-ok/

Nipun, (n.d.). Economics is the Science of Choice. Retrieved January 20, 2019 from, http://www.economicsdiscussion.net/economics-2/economics-is-the-science-of-choice-with-diagram/25116

Preece, J., Rogers, Y., and Sharp, H. (2015). Interaction Design: beyond human-computer interaction. Chichester, West Sussex, UK: John Wiley & Sons.

Turrell, A., (March 22, 2012). The Extinction of the Scrollbar. UX Magazine. Retrieved January 20, 2019 from, http://uxmag.com/articles/the-extinction-of-the-scrollbar

Navigate this post