Our challenge was to create a design system for interactive touchscreen kiosks for museums and exhibitions. Story Inc already had an exploratory prototype, and we were working off it to create a more consistent product. Our final design had to be visually engaging, able to support a variety of different kinds of information, and be easily replicable (i.e. some sort of no-code solution).
Story Inc's system was internally called “whimbrels”. The whimbrels were inspired by how content is laid out in webpages, specifically interactive articles that use multimedia elements to keep viewers engaged. Each whimbrel was made up of a system of “slices”; a variety of repeatable templates that content (text, images, and videos) could be dropped into and styled.
I worked on benchmark testing Story Inc's original prototype and conducted desk research on best practice examples. Our team was fairly close knit so we re-convened often to discuss our research findings, and worked as a team to analyse our insights.
We spent a day at the Te Papa museum observing how visitors interacted with the touch screens there. Several of the screens there had been designed by Story Inc as well, so it was really interesting to see which aspects of their work we could translate over to our design.
We user tested the original whimbrels Story Inc had created, to see how users would navigate the content and gauge their understanding of and engagement with the content. We focused on testing how they interacted with the content, and not their understanding of the text itself.
By talking to the Story Inc team we were able to better understand how they use interactive exhibits to craft an engaging narrative, their technical limitations, and how this product would potentially be used in the future.
We looked at best practice examples from across the web to see how “scrollytelling” websites made full use of their format. We also read academic articles that explored the challenges of designing the UI of very large touchscreens, specifically in museum contexts.
For this iteration, we focused on overhauling the navigation system and language switcher, as our benchmark tests on the original prototype showed that this is what users were most confused by. Outlined below are our main changes and the reasoning behind each of them.
We came up with an unconventional solution to test our prototype. The whimbrels were meant to be viewed and interacted with on extra large touchscreens, which we unfortunately did not have access to. Testing on a laptop in our early user tests had shown that people found it difficult to view and think about the whimbrel as anything other than a webpage. We set up a large iMac screen, and had users “touch” the screen of the whimbrel while we faked their interactions.
Our testing set-up had participants "using" an iMac as a touchscreen, while I did the actual navigation via mouse click.
By mimicking how whimbrels would be used in the real world, we were able to get our testers to think differently and provide us with some really interesting insights.
There were some larger trends that we found in both rounds of our usability tests. They were ideas that emerged by digging deeper into our findings and looking at the bigger picture, and we made sure to keep them in mind as we geared up to finalise our whimbrel design.
We identified a lot of accessibility issues in the original Whimbrels during our benchmark tests. We came up with ways to solve these issues, using heuristics and our expertise as designers.
In our mid-fi test, we didn’t test our changes as we knew they would function as intended - and they did.
To make our design easier to use, we had added many signals that it was a touchscreen you could interact with. However, this made people unsure of where they were meant to start.
In our final design, we grouped all the scroll indicators in one corner of the screen to minimise confusion.
In our tests, participants rarely identified the collage style gallery correctly, many of them scrolling past it without entering into the gallery itself. The second carousal style gallery was more commonly identified correctly and engaged with. This may have been because we only tested young participants, and this format is a very common feature of social media sites like Instagram. In the end, we decided to eliminate the collage style gallery, as it provided little additional information and did not seem relevant to use in educational contexts.
"Curio" is a system of delivering information developed where a still image contains "hotspots" or areas of interest that the viewer can click on to learn more, allowing users to slow down and explore a specific image. In our tests they were really successful at fostering engagement.
If you wanted to suggest an order that the curio touch points are best explored through (like a mini narrative), more thought would need to go into the existing hierarchies. A potential solution is a numbering system, or a path through the touch points like a treasure map.
For our mid-fi prototype we used content from Story Inc about “Golden Days” - their first major project that was exhibited at Te Papa.
Navigation was one of the major problems we discovered during our benchmark tests. The burger menu in the original design opened a full-screen page. Clicking on the titles in the menu took you to the corresponding section in the story. This did not match user's mental model's of what a burger menu does - most people thought it would take them to a home screen to find other stories. They had trouble using it because the titles in the menu didn’t match the titles in the story, and therefore, most people didn’t use the menu.
Users also often stopped halfway through the story because they thought they had reached the end. It was thus necessary to have some sort of wayfinding that would let users know their position, and how much reading they had left to do.
The difference between Story Inc's original prototype (top) and our version of the whimbrel (bottom).
Each whimbrel was made up of ‘slices’; blank templates that would contain content (image, text, and video), in different combinations that could be repeated to tell a compelling narrative. We thought of as many different types of relevant slices we could come up with, and then tried to fit in as many as we could in our final whimbrel.
A legend outlining every possible slice type was provided in our style guide for Story In's future reference.
After designing our templates in Figma, I explored Webflow as a way to actualise our prototype. It was quite intimidating at first; I’d had unpleasant experiences with website builders before, and was expecting Webflow to be similarly challenging. Fortunately, building a site in Webflow turned out to be easier than expected, and I’m happy to have been able to add another program to my designer’s toolkit at the end of this project.
I also led a demo session with the team at Story Inc, where I walked them through using webflow to style future whimbrels. It was a really rewarding culmination of weeks of research, and I was really proud of how much I’d managed to learn and create.
Besides the Figma prototype, I built two versions of our designs in Webflow - a copy of the Golden Days whimbrel and a "template" version that had placeholder copy and images that the Story Inc team could use in the future to create different whimbrels.
Our final product.
We also created a style guide that Story Inc could refer to when creating future whimbrels. It contained guidlines for typography, colour use, how to use slices, and a short guide to using Webflow to make whimbrels.
Finally, as part of our coursework, we created a poster that outlined our process of creating whimbrels. It was challenging to have to condense 3 months worth of work down to a single poster, but it was really rewarding to be able to view the journey of all our hard work.
The biggest takeaway from this project would be the importance of delegating tasks. Our team was fairly large, and after first working on every part of the process together, we realised that splitting up just made more sense. Constant communication between our mini-teams made sure that we were all on the same page.
Another really important lesson I learned was to fully embrace taking on new challenges and to jump at the chance to learn a new skill. Before working on this project, I had very little experience building websites, and was hesitant to tackle Webflow. But I’m really glad I took the plunge and just went for it.
Overall, this project was incredibly fun and rewarding to work on. I was lucky enough to be on a team with some really supportive people, which made every challenging moment feel less intimidating.