A Design For Life
Pursuing User Experience Agility
To be, or not to be, that is the question. Hamlet was contemplating death here. In Agile circles we don’t cover quite as morbid a topic. However, through continuous integration we do broach the subject of whether tools and techniques should live, evolve or die within our Agile process.
Technique X is not Agile. I hear engineers and leads alike utter this statement a lot. For some artefacts such as long, rambling requirements documentation this aversion makes perfect sense. At this point I imagine a choir of voices chanting in union the principle working software over comprehensive documentation.
I never thought I would see the day where x = wireframes would be solution to this equation. Even more frightening, that I would hear this feedback second hand from a client. Here I outline my thoughts on the importance of wireframes and mock-ups within Agile development practices, and ponder their place in Agile development processes.
No Education
Firstly, an education on what wireframes and mock-ups are is required. Clients and developers alike often confuse the terms. Even I myself use the terms interchangeably. On reflection, the confusion in our team is probably driven by my conflicting usage. Now is the time to make up for past sins.
A wireframe is a low fidelity outline of a screen and the data groupings it comprises. Designers may also include descriptions of intended interactions. Meanwhile, a mock-up is a mid-level static representation of the product appearance that users cannot interact with. Think initial sketch versus polished image. Prototypes are high fidelity representation of the appearance and interactions the final product will provide with which clients can engage.
There are many resources that can outline the differences between wireframes, mockups and prototypes, along with the tools that can be used to create them. This article by Marcin Treder is one of many.
Mind Eraser
I am by no means a designer. I have developed an appreciation for sketching screens through years of UI development. Far from having the top tools to create wireframes, I normally start by sketching option on a whiteboard and emailing the pictures. It takes a level of empathy for me to understand the motivations for considering these artifacts anti-agile.
Walking in another pair of shoes, I can see why designing a full screen could be construed as a Big Bang effort. Not only do the individual components need to be defined, but transitions and affordances must also be outlined. This might be construed as following a plan designed upfront, when adapting is critical. Others might argue it serves as documentation that is being developed in place of working software. To justify their place in our development cycle, we need to break these misconceptions.
Little Changes
Another fallacy driving these opinions is that wireframes are difficult to change. Linked to the all or nothing conjecture, it is perceived that swapping parts of the screen cannot be easily done. In this instance, evaluating numerous chart options with clients seemed challenging as it was believed they could not be swapped out. Therefore a decision was made without engaging users.
In reality, I often change mine through the swipe of a whiteboard eraser. Recently in the midst of an ideation brainstorm, I was able to create three different screen designs with the help of my trusty whiteboard. Carly’s corner whiteboard is becoming an ongoing joke as a result. These designs can be reviewed with clients and programmers alike. Designs can evolve iteratively through this method. Engineers just need to realise that rough scribbles are a valid design tool.
Draw the Line
There is still work to do to get buy in from our developers that sketches are a critical element in their client engagement. Looking forward, I envisage creation of mock up and prototypes without debate. They can help address some of our ongoing challenges in enforcing consistent design and common styling. Mock-up software such as Sketch has powerful capabilities to generate style sheets from designs. Automating our centralised style sheet changes would greatly reduce our current review overhead. With developers rushing to write code, it is important to highlight the output mock-ups can have in making time to develop more streamlined.
The effort required for collaborating over wireframes can make delivery of a feature in a single iteration exceptionally challenging. I’ve heard recent reflections from others in their adoption of UX within Agile development that will help. Generating designs ahead of time will ensure they continually feed into our development cycle. Regardless, these are a powerful tool for fostering user participation in our development practices. With client collaboration driving our agility, any mechanism that supports this engagement should be adopted.
Thanks for reading! Claps, as always, are appreciated.
