Personal communication between User-Centered Design (UCD) specialists and developers is important for communicating user needs and design solutions in agile development. In distributed projects where opportunities for personal communication are limited, the design documentation is an important surrogate. This study has investigated the perceived effectiveness of boundary objects in a distributed agile team, and their role in communicating target user needs. Six in-depth interviews with UCD specialists showed that the boundary objects rarely communicate underlying needs of the users but rather focus on interaction with the system that is being developed. The used boundary objects also do not work as stand-alone deliverables; they need to be explained and elaborated. Making the boundary objects comprehensive enough to be stand-alone is seen as too time consuming and not worth the effort. For agile projects with distributed teams, this creates hand-over and follow-up problems.

To evaluate and develop a service supported by an IT (information technology) system the intention to use the future service should be in focus. The technology acceptance model (TAM) and the theory of planned behaviour (TPB) can both provide knowledge about users' intention to use a service, making them good models to base formative decisions on. Unlike TAM, TPB is concerned with specific information related to the service context, and provide knowledge about what makes IT useable. We used an adapted version of the TPB as the foundation for a formative service evaluation technique called F-SET. We applied the F-SET to a case where two subsequent versions of a service prototype were evaluated. The first prototype was a description of the service supported by Hi-Fi design sketches showing what a web-based meal planning tool could look like. The second prototype consisted of both service processes and the web-based meal planning tool. To find relevant factors that influence future use of such a service, a survey of 28 informants was conducted with the first prototype. The second prototype involved five families who used the service for two weeks. The feedback provided by the families, based on the factors identified in the pre-test, influenced the future direction of the service development. Feedback from the informants was distributed between the service and the IT system, and the most common factors that influence the intention to use the service were time, price, usefulness and availability. Feedback included both positive and negative comments, as well as bugs and suggestions for improvements. We discuss potential improvements and what kind of information to expect from the different constructs of the TPB.