Agile design is a given for software development; flexibility helps us better contain unforeseen technical challenges and pivot on formerly expected features when they’re deemed unnecessary. Conversely, software development is a natural for an agile approach. Even when developing large applications, iterative development is a natural way to code.
But web development is as much design as it is code. When UX design first was introduced as part of the web process, we knew that it could provide the necessary strategy to aid early-stage planning for features, functionality, layout, and content placement. And so we would generate lots of wireframes, personas, and use cases up-front to help plan for what ultimately would be every unique page of a website or application.
In doing so, we would inevitably run into changes as the development or design process unfolded, which prompted us to take a look at our own approach to UX design and -- ultimately -- make it more agile.
So here are a few areas (and deliverables) we create in an agile fashion:
Wireframes are perfect for a quick design review cycle. They enable us to get layout, content, and suggested interactions in front of a client quickly without having to spend hours refining aesthetic features to present. And if the client wants to take individual elements from one wireframe and swap them into another wireframe’s layout, the result isn’t a mashup of two forced aesthetics. So the client (and our team) is able to focus on layout, functional
ity, and content prioritization early on. Plus, once the first slate of features are in development, you can build upon the initial wireframes to add another round of features as needed for that iteration -- which then requires another round of design layered into the mix. This snowball effect is incredibly efficient and does a much more realistic job of preventing wonky UXexperiences.
While wireframing is ongoing, we get clients thinking about design by presenting them with a set of artifacts that focus on color, fonts, and the other general design elements that will be used together as the visual language of the site. These design tiles are not full design comprehensives; instead, they are snippets of visual elements that should be reviewed in conjunction with the wireframes. (And they come in particular handy when we have multiple stakeholders who do not all need to be involved in each design review beyond initial approvals.) Once these design tiles have been reviewed with the wireframes and feedback is set, we can then more confidently design full-scale mock-ups. By taking this approach, the client then already has a sense for what she’s going to see when the design tiles and wireframes come together -- the result typically is quicker acceptance, approvals, and project advancement.
Breaking the visual design of the site into a set of defined, granular elements allows us to focus our design resources on only those elements that are the most prominent and necessary for conveying the visual messages of the site. This is more than just setting visual priority for the user -- it’s also a realistic approach to ensure that the visual design budget prioritizes the elements that must be visually present on the site. In taking this path, we are then more aware of how many of our non-priorities need to be re-negotiated within the visual design budget (or if the budget needs to be extended to accommodate their inclusion). Wireframing helps this process, as well, since it allows us to define these elements early on in the process, and either assign existing designs to them or mark them for a later discussion of priorities.
So now that we are making our user experience designs more iterative, the results of adopting this efficient approach continually indicate that a more successful product comes together quicker, with fewer unanticipated hurdles, and with more celebrating along the way.