Stephen Chalastra — Fri, 26 Jan 2007 14:53:16 GMT

Wireframes are a tool. A screwdriver is a tool. And just as it is not very efficient to knock in a nail with a screwdriver, there’s not much point using a Robertson screwdriver on a Phillips screw.

I work for a software consulting company and am faced with a wide variety of application and user types. It might occasionally be useful to have higher or lower fidelity wireframes than a typical Visio mock-up, but I find this to be the exception. It really depends on the complexity of the application, the phase of the project, the extent of the differences between this and what the users are used to, and so on.

There are several types of information that we want to get from user reviews. For some applications, the appearance is a high priority, and for these we produce a visual prototype. I find standard wireframes valuable for evaluating the data semantics of the panels: the field labels, priorities, groupings of data, and so on. And I find that if we introduce too many variables, the focus of a review can be diminished.

I’ve never heard the comment “is the application also going to be in black and white?” But I have heard over and over again something like, “I don’t think this blue goes with that orange.” If users are given the proper perspective up-front, they can typically not only relate to the wireframes, but appreciate them as providing a visual focus around which to wrap a text-oriented business requirements document.

Having said this, we’re on the cusp of changing technology and are increasingly moving from paged to rich internet applications, in which static Visio wireframes are not so useful. But that’s another topic.

Stephen Chalastra — Tue, 23 Jun 2009 16:36:05 GMT

I’ve come to appreciate the value of point 5 (collaborative design) while also understanding where Benjamin Ho’s initial skepticism is coming from. No, you don’t want design by committee – it can lead to a lowest common denominator solution. But you do want buy-in and ideas from all the sectors in Joseph’s Venn diagram. In the evolution from our early attempts to implement UCD to the present, we made lots of naive but valuable mistakes. Like going out to customers with designs they loved, only to find on showing the specs to the developers that a central premise was not feasible given the technology platform. Our conceit that interaction designers know UI design best was quickly punctured as we got some great ideas from developers. So now we’ve rechristened UCD as “user-centred development” in an attempt to institutionalize it and move it beyond a design “silo”. Our designs evolve based on usability expertise guided by early contributions from the overall project team and frequent user checkpoints. And we find as a result that we’re designing with much more confidence.

(Joseph, a quick question: in Figure 2, what would make Welcome User Name a 5 but current page number a 2 from the IT perspective? They both seem relatively trivial.)

Boxes and Arrows: Comments by Stephen Chalastra