Embracing "Franken-methods" in Agile

Our design process is heavily inspired by the design thinking framework, which covers researching, ideating, prototyping, and testing. Now that we're following the agile/scrum framework, we've had to squeeze our long yet rewarding process into a tight two-week time frame. The thing is— having just two weeks to do research and testing, all while iterating the designs— simply isn't enough.

During our first sprint, we quickly learned that the designs need to be ready at least a week before the sprint. In our plight to deliver on time, our biggest tradeoff was researching and testing. I know— a cardinal sin for UX designers.

If there's anything I've learned during my tenure at Summit, it's that we need to be open to unlearning. With that, we experimented with our process until we came across an approach that worked: franken-methods.

A Method to the Madness

Just as Frankenstein is a patched-together body, franken-methods are patched-up UX research and testing methods. Attributed to UX researcher Amanda Stockwell, adopting franken-methods means testing smaller hypotheses in creative ways. With creativity and flexibility, Stockwell shows that it is possible to deliver high quality UX research in two weeks.

What do franken-methods tell us? Instead of spending hours digging deeper insights, we're going for efficiency and proximity. Instead of thinking big, we're thinking small. What do we need to prioritize so that we get the results we need?

Given Stockwell's heavy focus on research and testing, we've adapted franken-methods to guide our approach to UX design. It might sound like franken-methods only apply to testing; however, I learned that they apply to any part of the design process. Taking inspiration from Stockwell, we have also spun the design framework on its head: Skip the foundational research, dive into ideation, and form a bias to testing.

Tips for Applying Franken-methods

Skip the foundational research. Work with what you have.

Narrowing down the problem space plays a huge role in doing UX research in agile. Talk to your team to learn more about your product, your business objectives, and constraints. Align your understanding of the product vision with the feature you're working on next.

From there, identify what you need to learn from your stakeholders and users. At this point, consider conducting quick interviews with the key people.

Form a hypothesis, then break it down into chunks.

The more specific our hypothesis and research objectives are, the more fruitful our research and testing will be.

When coming up with a hypothesis, start broad then dig deeper. Start by asking: What do we already know? What don't we know? From there, identify your research objectives for this sprint. Remember that we're going for efficiency and proximity. Our objectives, then, should answer the question: What should we know by the end of this sprint?

Go on autopilot.

When you're pressed for time, it's much easier to mistake your assumptions for gospel.

Scheduling "autopilot" sessions have been helpful. I block out times on my calendar to focus on researching and testing. Even if our wireframes and prototypes are not yet done, these already booked sessions with users force us to get feedback on our designs during the sprint.

Jump into your wireframes.

We don't need to wait for our users to start on a wireframe. With the information we already have and bearing best design practices in mind, we can get started on the wireframe as early as the start of the sprint. This way, we're iterating the wireframe as we learn more about what we're designing and how users interact with it.

I find that working on the wireframe helps me understand the problem and our solution better. It also leads to more questions that need answers.

When it comes to testing, embrace creativity and flexibility.

We have our working wireframes. We know what we need to learn from users. Now, we're in a better place to figure out which research and testing methods to use.

This is where the magic happens.

Let's say we have designs that are ready for testing, but we also want to know how users feel about an existing feature. If we had an hour with a user, we could dedicate the first half to usability testing. During the second half, we'll ask a few questions about how they currently go about carrying out a particular task and how they feel about it.

Any time we have with our users is valuable time. By carefully planning how we will test with our users, we'll be able to maximize the time we have with them.

This article was originally published on Summit Media’s Design Team’s official blog.