Experience and Graphic Design Process – Unformed Thoughts

As part of some recently expansive thinking, I’ve been jamming on the following theme recently as follows. So far, I’ve got some thoughts, but no good solutions, on streamlining the experience and graphic design process overall.

I was thinking about one of our projects (referred to here as “Project X”) in which we delivered HTML and flat graphic “prototypes” for the purposes of user testing, client approval, etc. during the design phase.

Ideally, the prototyping work would be kept in synch with the functional design in a similarly programmatic way as the content requirements were to the experience design (i.e. translating the page layouts to standard modules via an XML schema). In practice, this was achieved through verbal communication between the EAs and the graphic design/HTML team, without any formal link between the assets used by each group (either module layouts or even page templates). This somewhat haphazard system worked to an extent, but there were misunderstandings between those constructing the “look and feel” and those specifying the functional design that would eventually define the actual user experience. Feedback from the results of prototyping was also difficult since there was no common vocabulary either to define or describe page elements.

A partial solution to this is being used on the XYZ project. A Freehand “asset library” has been created by the graphic design team that allows EAs to build page layouts on a set of pre-defined templates to create near pixel-perfect “wireframes” which are very close to what will be rendered into HTML. These are complete with graphics (either final versions or placeholders) and indicative content. The graphic design team can update these assets as part of their work, with any changes automatically reflected in the Freehand pages. These “wireframes” are therefore actually design prototypes made in a joint effort between EAs and designers, and presented to the client as such (as PDFs). The primary advantage of this process is that the experience design cannot significantly diverge from the graphic design.

However, this is really only a graphic design solution. Freehand does not allow the attachment of documentation to the assets in the library, nor does it talk to the outside world. Business rules, functional requirements and any other necessary description of the modules and templates will therefore have to be done separately by annotating the modules and providing the necessary documentation against those annotations by hand in the traditional way. There will therefore be problems such as incorrect element numbering, document management and other housekeeping issues that were experienced on Project X and will need to be overcome in the same way on XYZ. It is also unclear how the documentation of the modules will affect the graphic design process, since annotations placed into the Freehand pages will “corrupt” the graphical page designs. Depending on the number of subsequent iterations, it may be that the graphic design will then start to diverge from the specification work, and the same problems that existed with Project X will return. Freehand also does not allow good interaction prototyping, and there are also problems with using Freehand documents in a shared environment; managing the asset library and with the weak document housekeeping functions (no paragraph or page numbering, for example). On PCs, there are significant performance and stability issues.

Unlike software development, TV and film production, or many other fields of activity such as architecture or industrial design, new media development lacks an “IDE” (integrated development environment). This, combined with the above problems, is why I became interested in Ubiquity RP, which seems to be a contender for the position of New Media IDE. Not only does it work by the same “asset library” principle, but also supports the detailed documentation of the assets created. The resulting pages built from the assets can be exported as an HTML prototype (optionally annotated with JavaScript tool tips) to demonstrate clickable interactions from page to page (via links, drop-downs, form submissions, etc.) at the same time as graphical layouts. It can also export a “documentation view” of the modules as a Word file, a feature which in future versions may be enhanced to include spreadsheets and/or XML.

Unfortunately, Ubiquity is not yet mature or flexible enough for serious use. While it doesn’t need to be a graphic design tool or replacement for Freehand (which would still need to be used to create and update graphical assets before loading these into Ubiquity’s library), it does need to provide more functionality than it currently has in order to be valuable enough to consider using on a live project. I have been in correspondence with the authors, and have suggested improvements, some of which they appear keen to implement, but others less so. In general, however, they are very much on the right lines and may provide a means in the future to allow the synchronisation of experience and graphic design, documentation, prototyping and (via integration with the Project X design artefacts) content collation and the programmatic creation of a solid basis for the build phase. It would be difficult to underestimate the positive impact of that on most projects.