The First Design Hardly Ever Wins. The Iterative Approach to UX Design
Welcome to the fourth part of our UXPin and DesignModo course on wireframing and creating design documentation. This course is meant to be an introduction to User Experience Design documenting techniques for new and aspiring designers, product managers and developers; and a solid refreshment of knowledge for experienced specialists.
In the first part you learnt what the difference between common design deliverables is: wireframes, mockups and prototypes. In the second part you had the chance to read my thoughts on the importance of aesthetics and context in design documentation, as well as to learn how to properly wireframe the basic layout of a website. The third part was dedicated to collaboration in the UX Design process.
This part of the course is really special. We will discuss the iterative approach to User Experience Design – a problem which is absolutely vital to wireframing and creating design documentation efficiently. Befriending iterations helped my design career and hopefully it will help yours as well.
Sounds interesting? Read on.
To iterate or not to iterate? What the hell does it mean?
Since the rise of the Agile movement iteration became one of the hot words in the whole New Technologies industry. We’re encouraged to iterate, we should close iterations of our work every week or two… Iterations are simply everywhere.
Sometimes I’m afraid to open my own fridge, as my cheese sandwich iterates there. You know the story.
Hardly anybody, though, wonders what the exact meaning of the term ”iteration” and ”to iterate” is. Let’s have a look at the definition in the dictionary:
Iterate |ˈitəˌrāt| verb [ with obj. ]
perform or utter repeatedly.
- [ no obj. ] make repeated use of a mathematical or computational procedure, applying it each time to the result of the previous application; perform iteration.
The noun has a respective meaning of “a repetition of a mathematical or computational procedure…”, etc. In music ”iteration” means also a repeated tune throughout the song.
To iterate means, then, to repeat some procedure based on the result of a previous version. To optimise, to improve, to improve the derivation of knowledge from previous versions.
And that, my dear friends, is the key to success in User Experience Design.
Oh no, it’s Lack of Humility – a Designer’s Greatest Enemy
The iterative approach is deeply rooted in the philosophy of User Experience Design. UCD, cycles of improvement, learning from users – that’s all connected to iterations. We, designers, really live on iterations.
Consider the assessment of the design in which, basically, there’s just one simple rule:
Always judge the design by the results that it causes in human behaviour.
Does your CEO’s taste matter? No. Does your girlfriend’s, or boyfriend’s opinion matter? No. Only User Interface performance determined by measurable goals matters. It might sound brutal, but let me just remind you what Steve Jobs told us about the nature of design:
“Design is not just what it looks like and feels like. Design is how it works.”
And of course quoting Steve Jobs doesn’t prove a point, but it nicely introduces the concept of optimized performance as the ultimate User Experience Design goal and its connection to iterations.
“Design is how it works.” Think about it for a minute. If the working part is crucial, you need to gather knowledge on your design’s performance. Without certain measurements you won’t have any idea on whether it flies or not; it would be absolutely impossible to assess if you had done a good job. Since design works in interaction with human beings you need to measure human behaviour to know if everything’s OK.
And when you gather knowledge on the performance of your design, you’re doing it for a reason. What reason? Oh that’s an easy one. You want to use the knowledge to correct yourself. That’s right, the nature of design itself pushes you to iterate on your work.
That’s the hard part of a designer’s job. You need to fight the “Lack of Humility” – the designer’s greatest enemy. That’s the super villain that gets you emotionally attached to your work and stops you from optimising it. I’d recommend fighting this till the last drop. If you kneel, you won’t stay focused on the “how it works” part and therefore you’ll certainly create a crappy design that will annoy users.
Stay humble, because first designs hardly ever win. Stay humble and iterate my friend. That’s the path to success.
Consider this story: I once designed an Android app. I crafted the prototype to fit the mobile screen and tested it on a couple of people from my company (a so-called corridor test – it’s a good bit of preliminary research that gives you some idea of how the design works). It didn’t go too well. My initial excitement was quickly replaced by shame. Some interface ideas performed quite well, but the overall impression of users was rather cold. They felt a little bit lost in the interaction (which the so-called Lostness Scale shows) and the interface lacked appropriate affordances to indicate usage scenarios (low success rate).
After a quick test I was pretty sure that this design was a failure. I didn’t try to persuade people to build it. Instead, I used knowledge gathered from the test and started over. The next iteration was much, much better. And the next one was the one that we finally built.
It performed great, but even so we were iterating after the launch to optimise it.
As you can see, I was constantly questioning my own work to create a great design. Humility was crucial. If I’d fallen in love with my first ideas, I’d have created a much worse design than I finally did. I was iterating on my design – testing it and creating new versions. That process was like a recurring tune in a song.
Honestly, I don’t remember a project in which my initial ideas remained 100% untouched till the launch day. There were always changes and optimisation. There were always new iterations.
Knowledge that we gather during the design process creates kind of learning loops. We design, ship (on early stages such as a wireframe, or prototype), learn (by user testing) and design again. We stop for a launch when the design looks ”good enough” and optimise it even further after the launch, since the data (real data, not an approximation) forces us to iterate again.
That’s very natural behaviour, since our design decisions are hypotheses. We’re making guesses based on our knowledge and experiences. It always requires validation and improvements.
So, dear reader – while designing, put your ego aside, stay humble, stay hungry for knowledge and iterate on your design in the search for optimised performance.
How to iterate?
Iterations are hard emotionally, but rather easy technically. If you’re already OK with questioning your work and learning from your users, the tough part of your work is done.
Time for the easy stuff.
First of all, iterations are always based on previous versions of your work. Previous work, even if full of errors, is a kind of foundation for your next iteration.
In any software you can do a new iteration by creating a copy of a file and naming it e.g. Project XYZ Iteration #2. Putting files in different folders may give you an appropriate order (really essential if you have e.g. 24 iterations). You’ll always be able to retrieve an older iteration, or compare a couple of iterations to see the progress.
It’s not a perfectly comfortable solution (you need to remember to manually copy a file and create a folder), but methodologically it’s fine.
Unfortunately for me it never worked. I kept forgetting about creating new iterations and I worked in one file. The result? I kept losing past iterations and I couldn’t retrieve anything from the history. That was very inefficient.
Therefore, at UXPin we’ve taken a different approach. Since iterations are crucial for the design, the button for creating a new iteration is placed in the top menu of UXPin App.
By pushing this button you’re sending a copy of the design to the history of a project. Automatically you’re editing the newest version. You won’t even need to stop your work while creating a new iteration.
All the iterations are stored in the history view. It’s a timeline of your design. You can browse through iterations and compare them.
Consider it the center of your iterative approach, in which you can:
- browse past iterations
- clearly see what the comments are on your current version
- see what people were saying about previous versions
- retrieve an old version (making it a current version)
All your team-mates and perhaps clients, will be informed about new iterations of your project. You can even allow them to comment only on iterations that you consider finished.
Iterations are useful not only when it comes to the creation of wireframes and prototypes. You can iterate on your persona’s and diagrams – checking if they are clear to your team-mates.
Exercise your skills now:
- go to UXPin App and have a look at your latest design (or quickly create it based on previous chapters of this course)
- show it to anybody (apart from your team-mates) and ask them to go through a basic use case
- record the feedback
- get back to UXPin App and create a new iteration of your work based on the feedback that you got
- go to the history view in UXPin and compare both wireframes
Do you see the difference? Repeat the whole exercise. That’s the iterative approach to User Experience Design.
Today you’ve learnt one of the most important truths of User Experience Design. UX Designers are not magicians that create stunning things immediately. It usually takes time and at least a couple of attempts.
And remember to stay humble.
PS. If you haven’t signed up to UXPin yet – it’s time to practice some design skills.