A great question came up today in my group critique for Designlab: How do you iterate quickly and efficiently?
As an alumni from the UX Academy program, this was a question that often popped into my mind during the most frustrating of times. Working in your own little bubble as a self-driven student can, in essence, be frustrating. Who is even keeping me accountable for these imaginary deadlines?! is one of the many thoughts I had. (Spoiler alert: It’s me. I keep myself accountable. And sometimes my mentor.)
Now that I’m in an environment where I actually work with other people to ship a feature, it gets a lot easier to empathize with my past self when I was still doing UXA. I’m assuming, from the many students worried about falling behind, that I was not alone in that context. Here are some things that I picked up over the past couple of months working on a feature that may be shipped before the end of the year, fingers crossed.
Also, if you’re short on time, skip to the TL;DR — Tying it all together section at the end of this article.
Feeling confident about your research
When I was in the trenches, getting myself motivated, and timing myself against the estimated time it took to complete each project, there was only me. That’s it. There were group critiques, which were helpful when it came to next steps, and the mentor sessions, which helped me figure out the next steps while also working on current issues, but there was no one who actually had a reason to say, “Yeah, this should be good enough” when it came to iterating. Sound familiar?
Full of woe, I looked to my mentor and talked with some of my other friends and coworkers in UX or product design. I talked with engineers and PMs and stakeholders. When do I know this is finished?
The general answer was that you are probably never finished ever and you need to learn to be comfortable and confident with what you’ve got. In a recent episode of Mixed Methods, Dan Perkel of IDEO talked about when he feels confident in finding something during the research phase:
“How confident are we,” and I guess it operates at a few different levels.
So first there is the research finding or something that we hear, and yes absolutely patterns. You start to hear the same thing, and especially when you hear similar things from people who you’ve intentionally recruited to be different from one another, then you’re like, “We’re on to something interesting there.” That’s one moment.
We’re also defined in a way by our constraints, so when we have a certain amount of time to work on a problem, we don’t get the luxury of saying, “Oh I’m going to go back and learn more.” We have to sometimes put design on paper. We try to present a breadth of possibilities. …
Talk to people who work in the same space…who aren’t designers
Reaching out to other designers, PMs, and engineers made the biggest difference in how I structured my time as a student. This was especially important in deciding when to say, “Yes, this is enough research” and “Yes, these wireframes will be sufficient.”
Doing work in an environment where I am working with a PM, another designer, and a lot of engineers gave me a massive reality check. If I were to go back and do another capstone for UXA, I’m confident that I can do it much faster, because I have a better sense of what I’m trying to achieve, and thus, have a better sense of what the minimum would be to address the initial problem.
Efficiency and sprinting: what’s the MVP?
I hate this term, personally, but the minimum is what I’m really looking at here. At work, I didn’t realize that I’d essentially gone through dozens of iterations without realizing it within the span of four days. Essentially, I sat through about four meetings with the PM and the designer that week. It looked sort of like this:
Day 1: Brainstorming
The three of us listened to rad music that stimulated our brains and did 15 minutes of quiet brainstorming with the one-pager on the screen at all times. How would we fix this problem?
The designer sketched out her ideas because that’s how she thought of things. I had unknowingly sketched mine out by putting big ideas on post-its and arranging them on the whiteboard in a hypothetical user-flow manner. The PM looked at our work, talked it out, looked at his research, and selected bits and pieces from each of our ideas. “Let’s do x” was said, and thus, meetings were made throughout the next week and a half.
Day 2: Initial Work
The designer and I worked on some simple user flows and super low-fidelity wireframes. Note that we did zero research here at this point. This is when I start to feel uncomfortable and panicky. She reassures me that it is the PM’s job to do the research. I calm down. We work based on the research we were given (and my domain knowledge of the topic). We have a visual. I’m to present it at the design review.
Day 3: Design Review
And this is where it all went crazy. My palms were sweaty. I calmed down eventually after pretending that it was another group critique. I presented. It felt like there were a million questions that came up after this. A lot of “did you think of x, y, z”? At first I felt a pang of imposter syndrome, but I realized it was a learning opportunity. This is exactly the kind of feedback that we should be expecting. I’ve been to the design reviews before as an observer, and at the end of each presentation, each designer always had some questions to think about for their next iteration.
NOTE: The caveat is that the critique is coming from an existing product, and the designers there were all in-house, and so knew the product in and out. This means that Phase 2 students in UXA, especially, may feel like the critiques are all coming from people who may or may not know much about what you’re designing. (As a side note to my side note, this is also why I invite Phase 2 students to my Phase 1 critiques if they have time — they have worked on those projects before and can give insight that comes from experience.)
Day 4: PM Check-In
We took our notes, made adjustments, and met with the PM. More questions appeared. This is when we decided it was time to go back to more research, more than what the PM had already done. BOOM! Research, ITERATED. Wireframes, NOTES TO ITERATE (once the new research was done).
New Skills: Have Options for Design Review
For those in my critiques: this may be helpful if you’re unsure of what to ask for when it comes to feedback on visual design. The designer I worked with had me create two or three different versions of the screen I was currently working on so that the next time we presented, the team would be able to pick out which one was better and which elements should be kept or dropped.
TL;DR — Tying it all together
This is the 1–2 minute version. I do recommend looking at the details, though. One of the things I freaked out about the most in UXA was not knowing exactly what I was doing and why, and if you also feel this way, the full article may help.
- Be confident in your research. If you’ve found a pattern, you’ve found a pattern. Work with that. You’re on your own UXA deadline, so don’t spend too long wondering if it’s “right”. Ask yourself as you design: When I put x into my design, can I explain why I did that with my research? If the answer is yes, you have done enough for now. Move on. Anything else is version 2.0.
- Talk to PMs, engineers, etc. Look at your LinkedIn network. See if someone you know works at a company with people in these roles. Ask if you can have lunch or if you could connect with one of them. (If you’re in San Francisco, the answer is usually “yeah sure”.) Go to general tech meetups and find these people. Ask them: How do you manage deadlines with your team? Note that if you’re talking to engineers, they are more than likely getting the final iteration of a project to ship, so their perspective on “finished” may differ from a PM’s.
- Have you found a minimum solution that could work? If the answer is yes, great! You have done one iteration! Do you now have more questions than answers? Great! You are now on track to iteration 2. You will continue to have more questions as you ask more people for feedback and as you gain more insights from user testing. It goes back to being confident in your findings. It is more than likely that you have already done more than one iteration without even realizing it. Woop!
- Is your final project decked out in jewels? Okay, I mean high-fidelity. And is it presentable, because that’s going on your portfolio. By the time you’re at high fidelity, you’re likely going to still have more questions than answers. Make a post-mortem or a next steps section. It will help with your next project. It will help interviewers know that this isn’t the end of the journey. It will help when you compare your post-mortem to your one-pager you made at the beginning, because you can see if you were on track.
Right, that’s all I’ve got for now. Keep the great questions coming! Remember, you got this. Be the Daenerys you know you are.