Why we need to test for constraints?
Design is never smooth-sailing. Especially for populations in low developing countries and less tech-savvy users, the idea of designing for error prevention helps to minimise risks and user’s pain points when they use the product differently from the ideal expected use case. A well-thought designed product is able to cover a range of constraints and still function perfectly up to its dedicated tasks.
It is the duty of Designers, Product Managers, User Researchers, Developers and Engineers to always have it surfaced and catered for when developing any products or services and to repeatedly conduct user testing and feedback to uncover the relevant constraints.
How to go about testing for these constraints?
In my previous article, I covered the four broad segments of constraints User, Medium,, Data, Network/Connectivity and what are some design considerations designers could include.
The following are 10 additional actions that could be tested for within your product.
Product test for learnability [Can fresh users (new to tech, new to business/service etc.) even use your product successfully?]
Product test for speed/accuracy [Can seasoned users get to their desired task/outcome as quick as possible? Can they walkthrough the intended design path without fail?]
Product test any exceptional hypothesis [Are there any potential unintended behaviours/use cases that have to be designed for?]
Product test for scalability [Can users still perform the same task with a range of screen sizes?]
Product test for visibility [Can users still navigate the screen with a min. resolution of ~480 x 800px, min. size ~4inches and with the lowest brightness settings/battery saving mode turned on?]
Product test for processing [Can users still perform the task with a ~8GB phone that has a few apps (games, social media, multiple tabs of a browser etc.) opened?]
Product test for information usage [Are users aware of how their data is handled or used?]
Product test for realism [Are users aware of the amount of personal information that is being used even though the testing product is just a prototype?]
Product test for network dependency [How will users react to the change in product usage when there is no network?]
Product test for network stability [Can users still perform the task on a slow/2G network?]
Conclusion
Though there are many more ways to stretch a product and test for possible constraints, conducting user testing with these in mind helps designers and product owners to be aware of the real-world scenerios. However, it is also important to note that these testing types should not be over-prioritised in intention as the main UX testing should take precedence instead.
Comments