Fotolia
How software prototyping beats requirements gathering
How do you know which features to code into the software you're developing? Application teams share tips on how to deliver ROI with prototyping, UX research and a design week.
The most difficult part of application development is how to determine a customer's actual needs and wants.
Development teams can carefully lay out software requirements, down to fine details. But should they? One school of thought suggests the best way to solve the problem of requirements is to ditch them entirely and instead opt for rapid software prototyping.
"There are no written requirements anymore," said the IT manager at the Legislative Data Center of the state of California. "Instead, we get in a group with the customers to find out what they want and need and go build a prototype and hand it to them to evaluate."
A streamlined, here-try-this approach bypasses the typical -- and laborious -- process of handing requirements among UX researchers, project managers, developers and testers. And even when that traditional process flawlessly captures requirements, customers aren't easy to please. There's often a disconnect between what they intuitively know an application must do and how they articulate demands to the development team.
In the Legislative Data Center's software prototyping approach, users are part of the process from the start, and they interact with a rough product within days. Software prototypes offer a dummy UI that has a login, official color scheme and other features to entice users into their working frame of mind. This inspires them to give meaningful feedback. The team goes so far as to print out color copies that users can write on.
User experience doesn't mean just the UI. The viability of an application depends on security, data architecture, APIs to integrate with other functions and software, and other factors. Don't underestimate the importance of UX to software quality, said Anne Vieyra, senior UX researcher at technology consulting company Saggezza, in Chicago.
"People get anxious about the drag on velocity caused by UX work," she said, but you have to design a feature that users will actually, well, use. "You can build the best-quality, reliable, high-performance feature with no ROI."
Editor's note: Throughout this article, experts refer to the customer and the user. Both mean the person interacting with the software, as opposed to the license or contract holder, whose priorities could be different.
Tips for success with software prototyping
No-requirements prototyping in software development is just one model to deliver software that meets expectations. It resembles a UX methodology called guerrilla research, Vieyra said, that is high-touch and informal interaction with the target user in the field. In an enterprise development organization, guerrilla research works best when it's used to go after one targeted question.
Prototyping works for the Legislative Data Center team for several reasons. The developers primarily deliver features and enhancements to existing products, rather than build brand-new apps. They also serve a specific and well-understood customer base. While this setup is for a government entity, many enterprise application teams also develop for an identifiable user base on long-established apps.
For many developers, the user performs specific tasks in a niche, so you don't need to please a broader public with the design, Vieyra said. She's able to test software prototypes with the actual users in a financial services role, for example. In any application project, know your user as well as possible.
Applications typically have multiple stakeholders and upstream and downstream dependencies. The goal of the new feature or enhancement that you are prototyping goes beyond customer satisfaction. Retail app developers measure success by conversion or profitability. For productivity workers, app improvement might show in number of tasks completed.
Try to build the prototype in the same language as the platform. The Legislative Data Center's IT organization works primarily with Drupal for content management and in Java.
If a bare-bones build isn't possible, enlist prototyping tools. Some popular choices include Marvel, InVision, Adobe XD and Flinto.
Don't aim for perfection. It takes too long and puts too much pressure on developers, which can cause them to veer off course. Instead, get everyone committed to a plan, and build momentum behind it.
This no-requirements approach to software prototyping and development might meet with resistance, so prove that it is better than the status quo. The California legislature team picked one small group for its pilot project. When the approach succeeded, the team grew adoption into more applications.
When guerrilla research and prototyping isn't a fit, break down silos to keep actual requirements at the forefront. As a UX researcher, Vieyra collaborates with developers, testers and business leaders. Together, they whiteboard the user needs, so everyone has the same understanding. At scale, virtual whiteboarding tools such as Lucidchart and Mural can synchronize a global team.
Above all, focus on users. Understand their needs, whether they are an internal worker, partner or traditional client. Incorporate their voices in a consistent, scalable way. "UX isn't just for startups and millennial companies," Vieyra said.
Now is the time to attack this problem. Development used to create applications to serve a purpose, said Helen Huntley, Gartner vice president, during her keynote at the consulting firm's Application Strategies and Solutions Summit 2019 in Las Vegas. Now, with digitization, development delivers experiences to meet exacting, important and even conflicting expectations -- fast.
"When you design, build and integrate applications, are you contemplating the overall experience at the beginning, or do you find yourself with a patchwork application that you hope provides a good experience?" Huntley asked.
Nothing too big to prototype
The time-compressed jump to a prototype works well for ambitious builds too, said Jake Knapp, author of Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, who also spoke at the Gartner conference.
In Knapp's approach to design thinking, work is structured to yield a testable product at the end of a five-day sprint. It requires a team of five to seven people to clear their calendars, which is why it's also known as a sequester. Sequesters have costs -- people are pulled off sprints, and you need a lot of resources -- but they're incredibly productive, Vieyra said.
Knapp's design sprint process goes as such:
Monday: The team maps out how the customer moves through the software. They focus on one key moment in this interaction and its key customer type. One team member is the decision-maker.
Tuesday: Team members independently develop sketches of how to solve the problem or deliver the enhancement. They don't brainstorm -- each person individually puts forth a viable answer.
Wednesday: The team reviews each option, discusses and holds a nonbinding vote on the best course of action. The decision-maker has the final say.
Thursday: Developers build a prototype that works well enough to test with customers. It's more than code; product presentation and even marketing and training materials can matter to the target user.
Friday: Five customers test the prototype, and the team assesses whether the product hit the mark or needs more work.
Design sprints might not shorten the period from idea to launch -- software builds, testing and security reviews take time. The time-boxed iterative design approach instead ensures that the features you code address the customer's actual demands, in a way that works for them.
"[Design thinking is] about analyzing and engaging ... in an open and unstructured way," Gartner's Huntley said. Application teams should use design thinking to understand internal and external customers' needs better than they could ever tell you. Knapp puts it bluntly: "Let's stop trying to make something perfect [and] just build a prototype in one week that we can put in people's hands."
After that phase, the team is committed to carry through to the final build, even if it takes months. And, equally importantly, product owners and developers recognize how design thinking adds value to the software.
