06 Mar 2008 0906H

Reworking wireframes

Probably one of the most frustrating things about this type of work is the amount of rework that is required due to changing or poorly gathered business requirements, and in fact, sometimes the business side is actually using hard code and layouts as a kind of sandbox for their own ideas before rejecting or accepting them. The problem with this approach of course is the sheer amount of cost that it entails: usually we strongly deprecate this kind of “agility,” in favor of “measuring twice and cutting once.” But, I recently learned a new wireframing technique at work which allows us to layout a widget or page once and then break it out into separate modules, and it’s the modules that get updated, not the widget on each and every page of a set of wireframes. One of the problems with this approach is that one loses the sort of holistic, high-level, “happy path” process flow, but that also can be fixed by including a flow with the wireframes. Obviously I think this approach is not just useful for user experience but also for designers of all kinds. Modularization and componentization of master elements, and updating just those elements to reflect changes, is much preferred than rework of pages and pages of wireframes.

Permanent link to Reworking wireframes

Filed under Information Architecture, Interaction Design, User Experience, Web, Work

3 responses to "Reworking wireframes"

RSS feed for comments on this post. TrackBack URL

08 Mar 2008 0659H

Steve Jack writes:

Yes, I can see that updating one componenet is better than updating 99 wireframes.

But why so against using code to create test pages ? The costs isn’t high, if the developer is good, and the testing is more accurate, as it uses the real thing, not a mock-up

08 Mar 2008 0853H

Gino writes:

In essence it depends on the development methodology in place. In a production environment for a large corporation, regular rollouts of functionality happen and there’s a pipeline of work lined up against strategic targets. But if there’s a lot of churn on a particular project, much less many projects, it really puts pressure on the rest of the work in the pipeline because of the resource drain. Not only is it costly in terms of corporate resources, which often involve whole teams of consultants, but it’s also costly at an individual level. It is very draining in terms of work for the particular team members who have to rework and rework and rework a particular job. Eventually you will lose key people, and it is very costly to replace the investments in knowledge and ability for good people, and often can set a project back quite a bit even if you have proper documentation. It is much less costly in terms of project management to ensure that solid requirements gathering happens up front involving key stakeholders such as marketing, operations, legal, so on.

Having said all that, there is an argument to be made for creating libraries of functionality which simulate common interactions or just even using paper. If you have a robust UX capability within your organization, you can use prototyping and usability testing after you’ve generated wireframes and approved them against requirements, roll the findings back into the design, and then push it to production. That is much less costly than creating public release quality code not backed by requirements or usability or anything. And then too it also promotes reuse of good code for other projects rather than creating piles of throwaway code which is different every time, for every project.

09 Mar 2008 1012H

Todd Moy writes:

I’d be interested in seeing what y’all have come up with. I’ve been playing with a similar concept and would like to see how our methods might differ.

And now it's your turn.

Fire your weapon, soldier. Just be careful of friendly fire. NAME & EMAIL required.

Your response