Use Prototyping to Maximize UX Efficiency in SAFe
Long, long ago, in the late 60s (sorry mom and dad), the roots of rapid prototyping began with our first hero Herbert Volcker. With a vision of programming machines to take on automated feats, he developed the first mathematical theory and algorithms of solid modeling. In 1987, our second hero Carl Deckard figured out how to fuse metallic powder into solid objects with laser light, aka 3D printing. By building products up a layer at a time, they could waste less and iterate on their ideas. These became the ingredients for the revolutionary practice of rapid prototyping.
In the 80s, software designers began to recognize they were stuck in the same pattern as engineers had been. Engineers used to plan a “finished” product and cut away from a larger material until it was complete. The same process was the basis for waterfall methodology. The rigidity of waterfall did not allow for a product’s design to evolve through iteration and testing, one layer at a time.
Inspired by the ideas of Barry Boehm and our other heroes, James Martin developed Rapid Application Development (RAD), a method of rapid prototyping software products. RAD is based on methods for gathering requirements, early prototyping, user testing, iteration, and re-use of software components. The strategic scheduling pushes product improvements back to the next iteration and breaks down communication barriers within teams. This process was formalized with his book, Rapid Application Development, in 1991.
Moving to the present (the history lesson is over–I promise), today we’re successfully using rapid prototyping in the latest evolution of agile practices, SAFe® (Scaled Agile Framework). For those unaware of SAFe, I will spare you another pile of words. Learn about it, at your own risk, here.
As a UX Designer, I have been successfully using this practice from within a feature team of a SAFe construct. The SAFe documentation does not clearly define the role of UX as my colleague Matt Kortering explains in his insightful article How UX Fits Within a SAFe Environment. Hence, we’ve taken it upon ourselves to inject our expertise and fight for the users!
In SAFe, prototyping is one of many tools used to conduct a Spike. Spikes come in two flavors, functional & technical. Functional spikes are used to elicit feedback for user interactions. Technical spikes are used for determining a technical approach e.g., build vs buy. For our purposes, we’ll break down an example of a functional spike. When dealing with design, we like to call them design spikes. Clever right?
Since spikes do not directly deliver business value, it is recommended that they are used sparingly. Like stories, they should be estimated, demonstrated and accepted by the product owner. Work with your feature team to determine when the spike fits into the current iteration. Sometimes, they may reside in the backlog until priorities align with the effort.
Let’s look at an example of how a design spike may be conducted. You’re a UX designer on a feature team that is working on a product’s native platforms (iOS & Android). It’s PI planning day, and you begin to discuss a story based on a product’s detail view interactions. At this point, the Program team has already worked to validate ideas that will turn into an actual project. Once approved, a project shifts to research, wireframe, and testing — further fleshing out the concept.
This is where it gets really interesting - when the project is “handed off” to a Feature team to build the idea. Although the story has been “handed off”, that doesn’t mean the deal is done. The program team is trying to get high-level ideas out the door, where it is the designers’ responsibility to take it to the next level. Working with your developers, QA, the Product Owner and Scrum Master, the designers complete the project visually and validate intent once produced.
You hypothesize that an alternative interaction pattern could perform better for Android users. But which pattern (if any) will be more intuitive for users? Rather than going right to the drawing board, I find it’s best to verbally raise the question within your feature team. Maybe your team raised the question to begin with–this is the beauty of these feature teams. Remember, there are no heroes–just a bunch of outgoing nerds who work together to make great things.
If your feature team is on board with exploring new ideas, it’s a great time to elevate the idea to the program teams. Work with them to collect more data, determine goals, and develop a hypothesis for your experiment. If time allows, it can help to visualize the interaction and put the work in context with basic user flows, wireframes, prototypes, etc. Use your judgment to balance the time you put into the spike and the time you need to dedicate to the active sprint. Once the team is onboard with the idea, it’s time to create variations and stage your test environment. The idea is to elicit pure feedback from real users in order to validate a concept.
Let’s take a look at a real-life example of a test we recently conducted. For this scenario, we applied some classic guerrilla A/B testing. It required at least two people to operate, one to conduct the interviews and one to record the results. We used four, two groups of two. Below, we have the design patterns we will use for live one-on-one interviews. The person in charge of documenting will need a “cheat sheet”. The cheat sheet will help keep our feedback consistent and most importantly, measurable.
In order to get the best results, we like to provide a user with “just enough” context. As shown below, we were testing swipe gestures for list actions. Since this cannot be represented well with a paper prototype, it was ideal to operate the test directly on a mobile device. I created the test prototypes with Principle and mirrored them on our test devices.
I know what you’re saying, “But Principle is only for iOS!” This is true, Android users are custom to some different UI patterns than iOS users. If necessary, we could create two versions, one for each platform, and test with corresponding daily users. Generally, the hardware won’t make a difference in how they go about mobile tasks. In our scenario, we document the user’s platform of regular use and consider their behavior accordingly. Make sure to consider the differences in each platform before testing, e.g. Android vs. iOS navigation.
During the creation of our testing materials, we decided on where we were going to conduct our testing. With some kind words and a little luck, we were granted permission to test in our client’s corporate cafeteria. We split into our groups and set out to run our testing. The trick to approaching strangers is to use some empathy. Here are a few tips we’ve found effective in conducting guerrilla user testing:
- Approach people at the right time -How would you feel if a stranger approached you with your mouth full of lunch to bug you about some study they were doing? Not cool–not cool at all. So wait until people are done eating. Don’t interrupt someone on a phone call.
- Be real and friendly - Tell them who you are and what you’re doing in a calm and friendly manner. You don’t want to give the tester a reason to distrust you. Many people are willing to help out if you come off as trustworthy.
- Offer a reward for participation - Sometimes a token of your appreciation makes people feel better about dedicating time to your experiment. At the very least, let them know they are contributing to the development of a better product.
- Keep it simple -Remember when I said to provide just enough context? Set the user up to make their own decision. Avoid asking leading questions.
- Bring some breath mints - If you drink as much coffee as most designers I know, you’ll seriously need these.
We won’t dive deeply into how many users to test. Nielsen Norman Group suggests 5 for most scenarios. We had free access to many users, so the return on time investment made it reasonable to do more testing.
Once testing was complete, we had quantified results that we could reflect on. We quickly began to see trends we could use to inform our recommendation. Keep in mind, if the results are negative or inconclusive, it could be a sign of what not to do. User testing is also about the elimination of concepts before expensive implementation. I took our results and presented them to our feature team during our sprint retrospective.
It was a great opportunity to get the product owner and development team’s initial reaction to the proposition. The product owner can consider the feature’s benefits and the developers can (and should) give some initial feedback in regard to the technical investment.
SAFe has changed the enterprise software game and our clients have already experienced massive benefits. The practice is not only profitable–it shifts company cultures. As UX and SAFe continue to develop, we need to make sure they develop together. Good user experience is an integral part of an agile methodology.
Rapid Prototyping is one of many tactics we designers can use to add value in SAFe. Consider the purpose of your prototypes in relation to their fidelity. I’ve used lo-fi prototypes to help my product owner decide on an MVP approach. They consist of nothing more than hand drawn sketches made interactive in InVision.
Use the right tool for the job. I’ve found each prototyping tool to have advantages and disadvantages. There are a wealth of tools out there. Some are better for mobile, others are better for complex interactions. Some are easy to grasp, others are harder to learn than flying a helicopter. Try to find tools that require the least amount of time and effort to accomplish your goals. This will contribute to rapid results and a higher return on investment.
Learn more about how Universal Mind runs SAFe for our clients here.