Comments on: Reworking wireframes http://www.everythingisdesign.com/2008/03/06/reworking-wireframes/ Chicago, user experience, interaction design, information architecture, information design, usability, graphic design, product design, strategy. Mostly. Thu, 20 Nov 2008 21:24:28 +0000 http://wordpress.org/?v=2.5.1 By: Todd Moy http://www.everythingisdesign.com/2008/03/06/reworking-wireframes/#comment-9418 Todd Moy Sun, 09 Mar 2008 16:12:50 +0000 http://www.everythingisdesign.com/2008/03/06/reworking-wireframes/#comment-9418 I'd be interested in seeing what y'all have come up with. I've been playing with a <a href="http://blog.capstrat.com/articles/where-the-wireframes-are-or-arent/" rel="nofollow">similar concept</a> and would like to see how our methods might differ. 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.

]]> By: Gino http://www.everythingisdesign.com/2008/03/06/reworking-wireframes/#comment-9417 Gino Sat, 08 Mar 2008 14:53:41 +0000 http://www.everythingisdesign.com/2008/03/06/reworking-wireframes/#comment-9417 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. 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.

]]> By: Steve Jack http://www.everythingisdesign.com/2008/03/06/reworking-wireframes/#comment-9416 Steve Jack Sat, 08 Mar 2008 12:59:07 +0000 http://www.everythingisdesign.com/2008/03/06/reworking-wireframes/#comment-9416 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 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

]]>