Powered by Metadata
For Web services to work, one piece of information must be distinguishable from another. Metadata accomplishes this by providing information about information, such as labeling a particular news story a business story. Creating user interfaces for easy metadata creation will be a prosaic, but important, element of designing for Web services. Services can break if there is so much as a misspelling, so helping people enter accurate metadata will be important. While this can be automated in some cases, in many cases it cannot.
Also, because entering metadata isn't the most thrilling activity, humans can get sloppy. The user interfaces that collect metadata must balance the system's endgoal without overburdening users.
User-Centered Design
The standard user-centered techniques we use now in design research and testing phases will work fine for building Web services. All of the data that's exchanged and manipulated by these systems is ultimately meant for the benefit of humans, whether it's for transferring money or finding a rental car. Metadata that's meant to benefit users should be derived from research on those users.
Presently, Web services are considered a technical issue, the domain of programmers. But in the process of building the technical infrastructure, human needs can get lost. Designers must insert themselves into the Web services design process early and often to represent users' needs.
Making the Invisible Visible
Industry evangelists tell tales of computers solving problems on their own, effortlessly searching the Internet for information and piecing it together to answer our every need. Once the computers are exchanging information seamlessly, we can fully automate many tasks and never have to think about them, right?
At least in the immediate future, this isn't the case. In reality, most "automated" systems require some sort of user interface. For example, autopilot systems have contributed to plane crashes because they either didn't properly alert pilots to a problem or compensated for a problem so quietly that pilots weren't aware of it. While most of our applications don't have life-or-death consequences, they will contribute to lost productivity and frustration if users can't properly interact with the systems.
When developing Web services we should ask:
- Will someone need to constantly or periodically monitor the system?
- Are there instances, such as error conditions, when the system should give the user some type of feedback?
- Will users have the ability to change the service, requiring a control interface?
- Will the service need to generate reports?
New Ways of Working
Because invisible, partially automated Web services don't exist as Web sites, they have the potential to change the way we design. Web services can go anywhere we can put a tiny Web server: in our cars, our phones, our televisions, or our wallets. Yet so much of our work focuses on Web sites, from the expertise we have, and the work in our portfolios, to the way we speak to clients. The advent of Web services means that design teams must stretch their skills beyond the browser.
Victor ([email protected]) is an information architect and experience lead at Razorfish, in New York City.
