Design myopia is a term I've coined for moments when I've spent too long on a design problem and get stuck. Once you've worked on a design for too long, everything starts making sense to you. After more than 3 weeks working on a project, it's likely that you have a hard time finding the weaknesses in your design. (especially if you've made it this far and have already put it in front of other people's eyes)
Design myopia is really a serious issue. As you get to the final 10% of a design, you can easily spend 25% of the total project time tending to these final details.
Some common psychological issues that arise toward the end of a design is the fact that you feel like an expert. If other people are confused by some small details in your work, it's because they don't think like you (you tell yourself). They haven't spent as much time as you have on this project, so they just don't get it.
In these situations, it becomes imperative that you don't continue forcing your way to a solution. In one instance, I walked a colleague through my screen flow and explained areas where I had been stuck. I explained the precise parts that users had experienced some confusion. Within 20 minutes, my colleague made a small change that I hadn't considered and helped me get to a more elegant solution.
Sometimes it's surprising to see the limits of user testing.
There are times when I've done user tests with users at different stages of a design from paper prototyping to high fidelity. One thing I've learned is that these tests are great for helping you to challenge your biases and see things from your user's perspective.
However, they seem to be less useful for filling in the blanks on smaller but critical details. The types of details that only an expert can discern and point out long before a user complains about it once the product has gone live.
Sometimes a good ol' discussion with your fellow team of designers and walking through several rounds of design reviews will take an experience/interface to the finish line.
One of the best ways to use user testing to test particular aspects of features or even an entire feature itself.
It's often not necessary to wait until you have designed an entire flow. The trick is to understand what it is you're trying to gain insight for or validate.
What do you do when you get stuck on designing a particular feature?
There are many ways to approach this and get over the hurdle. My natural instinct has always to go back to the problem and better understand the constraints or the problem. Another strategy, especially if you're short on time or if you simply just want to figure out the best combination of elements, you can simply test.
You have to be careful that you don't end up doing A/B/n tests on a small number of participants. User testing is really not the ideal situation to try and validate on some quantitative level whether or not to go with a particular design.
A far more effective approach is to use some combination of design studio with pseudo A/B testing backed by qualitative probing. What do I mean by this?
Don't simply ask your potential users, "Do you like A or B?" and then tally up the answers and go with the one with the most votes. DON'T DO THIS.
This can be an effective method when working with fellow designers/team members who may already be familiar with good design patterns and understand why you are approaching the design the way you are. (This is essentially dot voting.)
With users who may be using the interface, you have to understand that YOU the designer know more than the user. You have been thinking about this design challenge. You have interviewed far more users than any user of your product has ever done.
My approach focuses on framing small design challenges, getting users to express potential solutions, and then presenting them with my solutions.
This is often a fun method because the solutions I come up with in advance mirror what the users suggest - which makes me seem like a wizard. It's also a helpful method because it shows that I'm on a similar train of thought as my users.
However, the true value of this approach is that users can quickly point out the flaws in your design against the backdrop of their own recommendations. This helps the designer understand why the user is thinking this way. Most importantly, as you near the deadline of a project, it is helpful to begin optimizing what you have rather than exploring something completely different. The combination of brainstorming, and pseudo A/B testing with qualitative probing reveals new directions and insights within predefined constraints.
The goal here is not to receive design direction from your users. The goal is to understand how they're interpreting and responding to your design so that you can resolve underlying issues and pain points that surface when your user meets your interface. Rather than taking your user's suggestions point blank, you then need to reflect on the learnings and decide how to iterate and modify your design.
If you're interested in learning how this method might work for you, leave a comment below!
Currently reading Pragmatic Thinking and Learning.
Exercise: Thinking about Context
What is a current problem on one of your project? What are the different systems involved? Where do they interact? How are these interaction points related to the problems you're seeing?
My project has engineers, product managers, designers, and executive leaders involved. It's interesting to think about where they interact and where they don't interact. For example, the engineers work on their own, then come to an all-hands meeting to discuss the work. People who are less technically savvy have not been briefed about the problem or haven't had any time at all to understand what we're trying to solve. On the other hand, people who have a higher level view of things start throwing out ideas which can frustrate the engineers who have probably spent most of their solving it from a different angle.
There are several smaller interaction points that could be established to get different combinations of people together to tackle smaller chunks of the problem. For example, what are all of the things that the PMs care about? What are limitations of the data from the engineer's point of view? What are the concerns of users from the designer's point of view? These are different conversations that probably can't effectively be had at an all-hands meeting.
What are three things you've analyzed out of context that caused you problems later?
i.e. What else is this connected to that we should have considered?
1) Gathered a design team together to design an elegant solution for a scheduling feature without talking to the developers first and considering the timeline needed to implement the design.
2) Created an seemingly elegant feature for enterprise software without considering future maintenance efforts from software engineers
3) As an undergraduate researcher, I once did qualitative research on a political topic and didn't realize that my participants were doing more than sharing their perspective; they were trying to get me to join their side of their issue (yikes!)
As you'll notice, a key part of this 30-day challenge is to quickly apply what I learn, quickly execute on any challenges recommended by book authors/teachers, and create exercises if none exist.
Why is it so difficult to grow our skill set as designers?
I recently read Peak by Anders Ericsson, which shed light on this topic. It's a really fantastic book, and worth a read, no matter what field or flavor of UX/design you practice.
One research finding presented in the book still bothers me.
Experienced physicians with decades of experience were no better (and often, worse!) than physicians who had only been practicing for a few years.
No, that was not a typo. (I even bolded it for emphasis.)
Now now, Junior designers. Before you get too excited, don't mistake this as thinking you're just as smart as your senior colleagues. (That kind of thinking can get you into some serious trouble.)
The findings are saying that past a baseline set of standard skills and competency, it's really hard to continue improving our skills unless we have a really methodical approach to practicing. Ericsson refers to this process as deliberate practice.
In other words, just because we 'do UX' for the next 25 years, doesn't guarantee that we'll become expert designers. (Wait, what is an expert designer? That's a story for another day.) Most junior designers are able to close the gap between themselves and their senior designers mainly due to one advantage - training. If you've recently graduated from a solid bootcamp, art/design school, or related program from a university, chances are you've received state-of-the-art knowledge and experiences. You'll also experience rapid improvements when you get your first job, where you'll likely be mentored by a senior designer and learn how to apply your classroom training in the real world.
However, it's very likely that after a few years, your rate of growth and improvement will begin to flatten. After all, you'll be equal to or less skilled than your senior colleagues due to experience. How could you expect to become better than the master if you're simply working under or along side them?
Peak describes the ideal process of deliberate practice for becoming an expert.
However, I think with UX/design, there is some inherent challenges of applying Ericsson's framework, which he addresses in the book. The first being that there is tremendous difficulty establishing the definition of expertise in UX. The field is widely misunderstood and there are more flavors of UX being practiced than Ben and Jerry's ice cream flavors. Secondly, while UX tries to be as research-oriented as possible, it inherently has a high degree of subjectivity with regard to the quality of the final product.
If we are able to apply Ericsson's model of deliberate practice to design, we will have made tremendous strides. That's a project I'll be working on in the background.
But not all is lost. I am designing an experiment (not really an experiment in the scientific sense...it's just a sexy word) to see if I can rapidly expand the depth of the various UX skills I use on a day to day basis.
I'm (tentatively) calling it the 30 Day UX challenge.
Over the next month, I'll be sharing the plan, updates, and insights.