Tying Up Loose Ends For User Testing

Ahead of the next big leap🚀, we wanted to streamline user flows⚡️, finalise basic features☑️ and get ready for testing with real people😬.

With all big features for the UnscrewMe MVP being implemented, we started to focus on some usability optimisations. Beyond reviewing existing user flows, we also wanted to get ready to obtain real user feedback.

Now, at the moment we do not have real users yet — but we have a bunch of friends who are interested, and most importantly, haven’t seen the current development release yet.

Prioritising smooth user interaction

Our first step to getting everything ready for user testing was to make some tweaks to a couple of the features we had implemented over recent months. We made the decision not to add any more features to the MVP at this stage, but to look just at the current feature set instead and streamline the processes as much as possible before we even start user testing. This meant no refactoring of business logic and no performance optimisation. It basically came down to adjusting the user interface a little bit and reviewing some design decisions with the goal to make using the web app a little bit more efficient.

One of the bigger improvements was to avoid a context change on the calendar page. We wanted to implement this as part of the MVP, but at some point during the implementation, we thought that maybe this additional event list that opens dynamically on the same page was not needed. After playing around with the test release, it became clear rapidly that adding this dynamic list right on the calendar page would be beneficial to make detailed information about the wine tastings for a particular day accessible more quickly and avoid an unnecessary page load, which would take the user out of the calendar context.

It was a straightforward improvement, but required some refactoring to one of our core Vue.js components. By adding a so called prop to control some aspects of the way the information got presented and formatted allowed us to avoid duplicating work and did speed up the development by reusing existing code.

Picking improvements which add value

With our Lean Canvas in mind, prioritising which improvements make sense and which can be made later was a crucial decision to be made at this stage. For example, one improvement we considered but ultimately decided against implementing now was the migration to Font Awesome 5. We did migrate the pre-launch page, because we wanted to use the Vue.js icon — to highlight that an article got included in the Official Vue News #90 a few weeks ago. Some adjustments were required, but it was easily doable and the upgrade was not very complex. However, it turned out that the integration of Font Awesome and Vuetify, or Vue.js in general, still had some issues. We could most likely have worked around the problems, but just for adding a non-essential icon to a subpage, it didn’t seem worth the effort.

Difficult and complex changes could have impacted our test and release timeline. Not least to keep ourselves motivated and swiftly move towards our goal to complete the MVP, we opted to look out for the easy pickings which would add value, without too much workload.

Another option to add value and not delay our next steps was to define minimum viable functionality for certain features. Again, it was on the calendar page, where the calendar looked somewhat untidy on mobile phones.

Recently, I went to a talk at the IE Business School in London by Kevin Sigliano (@kevinsigliano) about “The ROI of Data-driven, Digital Transformation”. One detail he mentioned confirmed to me the importance of mobile users. Based on conversations he had with online marketing managers at a couple of companies, between 60% and 70% of users now make the first contact via a mobile device. And as mobile is still becoming more and more important every day, providing a sleek product on mobile was a key priority. The more flexible option would have required some additional logic, but we could achieve our primary objective with a pretty simple change — so that’s what we did.

Living with imperfections

After deciding on our priorities and the scope of the improvements, we got a product which implements all the very basic features. Of course, every feature is far from perfect and can be improved, but to take the product to potential users, we mainly needed a functional release. Getting the web app into a state that it worked to perform meaningful UX research was our main objective right now.

In a way, this initial release is not much more than a proof of concept. The interesting detail is that we are less focusing on proving the technical concept, but more on proving the concept of the idea, by starting conversations with people, who could become users in the near future.

Reaching out early in the process should help in picking up what users really want. Giving potential users a web app that looks and feels like a service that they could find online is an important step. This should make it easier for people to compare and reflect on what they can see and interact with, instead of having to imagine a product from just a wireframe or even a verbal description.

Preparing for user testing

To be able to validate — or invalidate — our design ideas and choices, we needed to provide our testers with a framework. By asking the right questions and providing standardised tasks, we could ensure to cover all areas we view as important. Also, having similarly structured test protocols would make consolidating our results and drawing conclusions easier.

So, before we could start scheduling user tests over coffee or wine, we needed to devise a test plan. For a first round of user tests, we did not want to limit ourselves to functional feedback. We were also eager to learn more about our potential users in general — what devices they prefer to use, what tools they rely on to stay organised and where they usually get their information about events and wine tastings from. Like for anything we write, after drawing up the test plan draft, we got it reviewed and discussed it with two friends who support us throughout our journey. This sense-check helps to focus on what is relevant, and minimise the risk of (implicit) bias by improving the wording of questions and tasks.

The final challenge in preparing for user testing was scheduling the interviews. For this early-stage testing, we only wanted to take it to a small group of people, best with different backgrounds to give us a broad overview. We were aiming for three to ten interviews. Two interviews have already been scheduled and for two more we are in discussions about suitable dates and times, so we hope to gather first feedback over the coming weeks.

We are already excited about what observations and preferences we will identify from the first round of user testing and look forward to improve our product, before we put it online and “test” it with a wider audience next.

Analysing the user feedback and integrating what we learned into our product will be the topics we are planning to cover in the next article.

(Once again, Curators Coffee Gallery and Kaffeine in Fitzrovia reliably provided a couple of cups to help us completing this article — and scheduling the tests. But we also went to temper Covent Garden and were lucky enough to get a few tasters and then decided to have a delightful glass of Riesling from Bolfan Vinski, located in the Zagorje region in the North of Croatia. The Riesling was kind of typical, beautifully balanced with strong notes of fruits but also nice mineral characteristics too, even showing a bit of petrol in the nose.)