Many times a designer’s job is to create a solution based on an identified need within a pre-determined set\u00a0of constraints. In the context of designing for business – the constraints can be a release schedule, a\u00a0product launch or simply the evolution of a larger strategy.<\/p>\n
One interesting scenario\u00a0that I’ve encountered is in fact the deconstruction or the dismantling of software within the context of a larger system. Feature extraction.\u00a0The constraint manifests in designing a feature out of the software. Think of an old house that needs to be remodeled. The first step is to take all the walls down to studs and then begin the remodel.<\/p>\n
So much effort goes into planning, researching, designing, communicating, iterating *building* … but it’s rare as a designer to consider how your design will be dismantled or “undesigned”. Most of the work that we do is creating;\u00a0not elegantly destroying. This type of design is some of the most complex design I’ve ever done. It’s more like surgery in fact.<\/p>\n
A distinction we often make in designing software is that it can simply be thrown away. There is no material cost. Software products die or are abandoned. Features are left unfinished (this is UX debt in a large system). This issue is probably more salient in industrial design where the designer considers materials and the environmental\u00a0impact of design\u00a0decisions (hopefully …\u00a0the track record of mobile device manufacturers is abhorrent<\/a>). Hardware isn’t cool ,\u00a0it’s fucking dirty…but I digress.<\/p>\n There are many metaphors to describe the process: swapping out the engine as the car is driving, building the rocket ship as it’s launching, etc. Deconstruction design is all about minimizing impact, making sure everything is patched up as you design interactions out, slowly backing up to the door, exiting and closing it\u00a0behind you.<\/p>\n","protected":false},"excerpt":{"rendered":" Many times a designer’s job is to create a solution based on an identified need within a pre-determined set\u00a0of constraints. In the context of designing for business – the constraints can be a release schedule, a\u00a0product launch or simply the evolution of a larger strategy. One interesting scenario\u00a0that I’ve encountered is in fact the deconstruction […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-1127","post","type-post","status-publish","format-standard","hentry","category-sartor-resartus"],"_links":{"self":[{"href":"https:\/\/www.chrisrivard.com\/blog\/wp-json\/wp\/v2\/posts\/1127","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.chrisrivard.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.chrisrivard.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.chrisrivard.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.chrisrivard.com\/blog\/wp-json\/wp\/v2\/comments?post=1127"}],"version-history":[{"count":0,"href":"https:\/\/www.chrisrivard.com\/blog\/wp-json\/wp\/v2\/posts\/1127\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.chrisrivard.com\/blog\/wp-json\/wp\/v2\/media?parent=1127"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.chrisrivard.com\/blog\/wp-json\/wp\/v2\/categories?post=1127"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.chrisrivard.com\/blog\/wp-json\/wp\/v2\/tags?post=1127"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}