How to communicate design from structure to visual design effectively?

Question

I try to solve a problem, I've encountered several times: the lack of a common communication basis while designing software. - a basis for PM, Project Manager, UX Designers, IA's and Visual Designers as well as Developers.

Sure there are Mockups, Sitemaps, UI Patterns, Lofi and Hifi-Wireframes, but still there occur translation errors. I believe this is due to the narrow view every project member has - which is great for problem solving, but bad for communication. I think, most problems pop up if a project moves a stage upward - the stages James Garret introduced - and new project members with different views enter. Then the documents made for the former stage need to be translated to the next stage (with the mentioned translation problems)

If one maps the common tools here, one will see that they focus on just one stage. Like a Lofi wireframe for the skeleton stage. Sitemap for structure stage. UI Patterns and Hifi Wireframes for the surface stage.

Do you know a kind of modelling/communication language, that spans across the stages?

or even just structure->skeleton and skeleton->surface.

And is

• understood by non-designers
• tool independent (i.e. no InDesign or Photoshop)
• easy to maintain
• easy to learn
• simple and not to detailed

I like James Garret's A visual vocabulary for describing information architecture and interaction design for spanning structure and skeleton stage. For me, IFML and UML enforces the focus to deeply on technical apects, which I dislike. And the topic UI key dimensions and flow diagram is sound, but dedicated to one stage only.

Answer 1

English [or insert your native language here].

Sorry to be snarky, but I don't see how one formal language could meet requirements from "what a user wants it to do" to "what classes the software will have" to "what database tables are needed" to "what the screen looks like".

The point of languages like UML is that they allow formal, precise description within a domain that is clearly defined. Your problem has no such domain. Furthermore, any formal language requires everyone to learn what it means; otherwise they can't use it as a shared medium of communication. It would be unrealistic to get such a wide range of stakeholders to learn a new way of communicating.

The reality is that developing software is complicated. It requires precise communication between a variety of professions, and such communication is difficult. One cannot escape a problem like this by introducing more formalism. Attempting to do so often exacerbates the problem rather than solving it. Indeed, many people are skeptical even of things like UML for this reason.

In short: I think the solution is simply working hard to improve communication, and in particular, working on communication and inter-domain knowledge at the points where the project crosses boundaries.