On the feature complexity of secondary features
I was thinking about my article on the concept of automatic keyboard language switch by iOS and wanted to share my thoughts on feature complexity of secondary features, i.e. features that are not used or expected by every user.
Whenever a secondary feature shall be implemented, it’s always not as easy as it seems from an UX perspective. There are users with a good technical understanding that benefit from a feature and there are users that do not benefit from a feature or will even be confused by the feature. Sometimes fewer features is more.
A new user might not grasp the concept of different (language) keyboards, how to switch between them and how to add or remove them. A new user without prior knowledge, e.g. first time smartphone user, could be lost on the sheer number of possibilities and the complexity of a modern (mobile) OS.
An enjoyable video on this topic is game developers watching how speed runners are playing their game. The developers spent hundreds of hours on developing the game thinking they know everything, and yet they’re astonished by how many shortcuts and loopholes the speed runners are able to use.
An automatic language switch might be exactly this: useful for “power users” and confusing for everybody else. The UI could be structured in a way that only the power user that is looking for such a feature will find it - somewhere behind a toggle deep in the system’s keyboard settings. This is the approach that probably many developers and designers choose.
Developing new features involves multiple cycles of testing, designing, development and feedback. Especially on platforms with a big userbase (such as iOS) gathering feedback is easy1 and almost mandatory. Talking to multiple customers is essential. However, you need to be careful to identify what the user really needs and what he wishes for. Therefore, talking to multiple users is just as important as talking to them in general. Also, the primary users are not the developers but rather a different group of people2. This makes understanding the core of a feature more complex than the initial thought (by a developer or designer). The developer does not know what the customer needs.
However, even user feedback can be misleading. There’s a correlation between the number of active users and the amout of feedback active users give compared to non-active users and their amount of feedback. Users that are in general not happy with an application aren’t willing to provide (instructive) feedback. ↩︎
This is the case probably everywhere in software development. Sometimes, developers, designers or founders use their own software, but this can make it even worse: they think every customer is using the software the same way as they’re doing and thus do not listen to their customers’ feedback and implement features they need (or want) and not the features the customers need (or want). ↩︎