203CR ‘Yes Buts’ for using UCD for pervasive computing?

Many User Centered Design techniques could seem applicable for use when designing pervasive computing, however because of the very nature of pervasive computing, many of the methods used in UCD are not always the most suitable.

UCD is all about designing interactive technology to meet user’s needs. The problem is that with pervasive computing, the requirements of the user can be so specific and niche that they may not really be expressed as huge needs when undergoing research. Also UCD can cut down on design costs, however when producing technology that no one has fully experienced beyond lo-fi prototypes, it can be expected that refinement and tweaking are needed to produce a fully fledged working version.

User experience is limited, because often in pervasive computing there are no activities similar, this means that a large proportion of UCD can be inconclusive. Sometimes the activity is to use the new pervasive distributed system and that alone, so no other precedents apply. To get over this hurdle designers must explain and document all sides of the user experience so that interviews and initial design briefs can be based on actual user’s requirements. The users have to fully understand the design concept and its use, else theoretical questions regarding their needs and requirements could not take place.

Requirements are also subject to massive variance and change, for example if the environment is outdoor and mobile, the environment is constantly changing and therefore the design must be able to adapt accordingly.

When designing pervasive computing it is often easy for designers to create requirements before they understand the tangibility of their visions. Pervasive computing is on the forefront of integrating technology with existing environments, so the technology being used has not been fully tested, and often its capabilities are not fully known. This means that it can be hard to know your hardware limitations when creating UCD principles and requirements, and time needs to be invested in researching possibilities.

When creating a lo-fi prototype it is the aim to transfer the same design principles from the concept, across to the easy to produce prototype. However when creating complex distributed systems across massive areas and huge variance of environment, a lo-fi prototype will often not be entirely transferable. Prototyping using a human to mock a computer interface is possible, but much research has to be conducted in order to try and take into mind the scope and depth that user’s behaviour will vary with pervasive computing interaction.

It is evident that to ensure that your time spent researching UCD is not wasted, you should not work with entirely “theoretical” user feedback, based on mid or lo-fi prototypes. It is indeed a price to pay, but in most pervasive computing circumstances, user feedback and UCD should occur before and after a working product is designed. This means that often the initial “beta” product will cost almost as much as the final product, but it will be heavily tested and stressed under ranging conditions and with different usability aspects in mind, so that a more user revolved product can be produced.