There are a lot of different approaches to designing a software product. Some place an emphasis on technical aspects; for others it’s project management. Many try to take an end-user perspective and incorporate usability factors.
Unfortunately, the problem with usability is it can become too focused on functionality.
Our kiosk application is used by visitors to check in when they arrive at a company’s front desk. A few months ago when we started working on version 3.0 we had a good idea of the features it needed to provide. This long list of features resulted from hundreds of discussions with our clients over the last couple of years.
The issue is though, if you design your product from a feature list, you risk ending up with a product that lacks consistency and personality. It’s just a set of functions laid out next to each other. Often such a product does not ‘feel’ right because the features don’t fit together. It’s too focused on functionality.
So, instead of thinking about what kiosk 3.0 needs to do, we started by asking ourselves what kiosk 3.0 needs to be.
In order to do this, Loucas (UX engineer) asked each of us the following:
“Imagine kiosk 3.0 is a person. How would you describe this person? Please think about it for 10 minutes and list down 5 adjectives on Post-It notes.”
Ten minutes later, once everyone had posted their notes on the whiteboard, the result was surprising: as a group of 5 people, we could easily have come up with 25 different traits. Instead, all our ideas boiled to the 5 same personality traits which determine who Kiosk 3.0 will be:
There are a couple of really big advantages to this approach to software development. The first advantage is it tests the assumptions and beliefs of your team members and helps to surface, clarify and resolve core disagreements early on in the process. This ensures we are all aligned with a common set of agreed functions.
The second advantage is it provides a good reference check when you develop your product and run into contradictions. Let me illustrate this with one of the main new features of the 3rd version of our kiosk: ‘Smart Questions’.
At Proxyclick we are determined to transform the check-in process into an experience for the visitor. The experience starts way before check-in and ends long after check-out. We believe in the importance of the visitor journey so much that we have dedicated it an entire section of our blog.
We learned from our customers that different visitors to their organization may require different check-in processes. The obvious example is the ability for the visitor to check in, in their own language. There are other less obvious examples we heard from our customers:
That is why we introduced what we call ‘Smart Questions’, which is the ability to ask questions, display messages or require a signature based on previous responses provided by the visitor.
When we designed this feature (or any other one), we often looked back at our notes to check if what we designed was in line with the attributes we wanted for the new sign-in screen:
Of course. As said above, smart questions not only adapt to the check-in process of the company, but also to the specific visitor.
This is less obvious and generated some debate. When a visitor is asked which countries they have visited (and may not be allowed to check in based on the response), this raises the question of the visitor’s "rights" versus the company’s "rights".
Our view on this is twofold:
This generated some discussions too. Indeed, beyond a certain point, if you give too much freedom to the company in designing the smart questions, it soon results in a check-in process that is complex to understand and difficult for visitors to follow. In particular, if you allow organizations to put more than one question on a screen at one time, you could end up with an illogical and confusing flow, as following questions depend on previous responses.
We solved this by allowing companies to put only one question per screen (and not more).
Surely, this will come as a constraint to some organizations (who would for instance have preferred to put 3 questions per screen). As a consequence, the kiosk loses a bit of its adaptive nature. But that's fine, as losing some ‘adaptive’ capability helps preserve the ‘straightforward’ nature of the kiosk.
Treating your product as a person won't replace the need to define what features need to be developed, or even better, which tasks need to be performed (we're big fans of the job-to-be-done approach). You'll still need to go through that phase.
But defining the product-as-a-person will help you define how to develop a feature (does it fit into the whole?, how far should we develop it?...).
Also, we believe aiming at the maximum on every personality trait is often an illusion, as there are inherent contradictions between them. And that's fine, as long your compromises are conscious and consistent. After all, successful products are often subtle and sometimes coherently bring together contradicting traits. Just like humans actually …!