Despite a blurry separation between roles in software creation, there often is a personal tendency either towards Information Architecture and Business Analysis or towards Interaction and User Interface Design. In the Data Web space, tool developers and demonstrator creators still seem to be stronger in the former than the latter.
Now how do you get from here to there (where "there" equals more user-friendliness)? Maybe getting a better picture of the different roles your tool has to satisfy can help. As well as deciding on the target audience in case of an end-user-facing application. For example:
- Data Providers: main focus is getting a schema and related data published without loss of quality.
- Data Engineers: cares deeply about schema mappings.
- Information Architects: agile schema change management.
- Interaction Designer: simple APIs to integrate real data into highly customizable templates at the post-mockup stage.
- Content and Data Editors: convenient editing tools.
You should need less roles to describe the target user group for a particular application (or this is a sign that your focus may be too wide):
- Curator: convenient editing tools.
- Citizen: wants to be heard, wants browsing tools.
- Data Journalists: want navigation and convenient extraction tools.
- Data Analyst: comparisons and insight generation.
For an end-user application, you can often narrow down the target audience and then create a highly tailored user experience. Less so for a tool. And it gets even harder when your tool implements a specification whose purpose is to broaden the reach of a technology. Like the Semantic Web and its younger relative Linked Data. They both want to simplify Knowledge Management to a level that it can work across the Web. The early adopters in this space range from AI pros to front-end enhancers.
I think it's worth spending the time to ensure the best possible experience for each of the roles you can identify for your app or tool. Even if this means that you have to create several tools that operate against the same source. Let's say you use RDFa or microdata in your HTML templates. You may then need separate visual access methods for Data Engineers and Interaction Designers. Similarly, you may please you product development team with a bespoke API, while the labs team appreciates a bleeding-edge SPARQL endpoint to explore new options.