What is Rapid Prototyping?

The DroidDevCast is a new podcast brought to you by the team at Esper, exploring all things Android, mobile DevOps, and open source software development. On our third episode, Esper Content Marketing Manager and podcast host Rin Oliver is joined by Upbound Senior Software Engineer Daniel Magnum, who works full-time on Upbound’s Kubernetes infrastructure management software, Crossplane.io. Together, the two discuss all things rapid prototyping, what makes for a usable and efficient low-fidelity prototype, explore best practices for startups hoping to scale, and how individual contributors can make an impact in open source.

Listen and Subscribe: YouTube | Apple | Simplecast

Breaking Down Rapid, Lo-Fi, and High Fidelity Prototyping

For developers that are getting a handle on their user’s needs, low-fidelity (also known as Lo-Fi) prototyping is many times the first step in the development process. Lo-Fi prototyping stands out as being particularly beneficial when it comes to understanding the basic, core fundamental needs of your users. Magnum explains that most of the prototypes he works on daily are either part a system that he’s building out, or a Command Line Interface (CLI). While this deviates from the typical front-end interface prototyping and programming, it is often straightforward. Magnum mentions that Crossplane, for example, has a distributed system behind it, and a variety of things being created on its API server, or on cloud providers. From a CLI perspective, these can often be mocked out using a Lo-Fi prototyping approach.

“So I definitely think starting from a lo-fi approach and saying, ‘Hey, if you issued this command and got this information back, let’s imagine that’s actually happening,’ then you can get a feel for the user experience folks want, and then you can kind of build that behind that interface you’ve presented. And then, speaking with limited knowledge to the kind of UI side of things, you can give that same sort of UX feel without necessarily having the most polished UI,” says Magnum. 

For early-stage companies, there is sometimes pressure to define what a product may look like without having truly mapped out the user experience. This is another instance where lo-fi, rapid prototyping, and high-fidelity prototyping shine.

“What you really want to think about is how someone progresses through using an application or a system. And you can do that in an extremely low-fi manner, right? Because you’re just going from one thing to the next, and then you can kind of get some customer validation there and then build up the experience around it.”

High-Fidelity Prototyping Tips: Take Advantage of What’s Available

When touching on high-fidelity prototyping, Magnum mentions some best-practices for developers building software, with his main takeaway being to take advantage of existing libraries. While there is always the possibility that a developer may need to achieve functionality beyond what a library presents, Magnum notes that for those doing the prototyping, you can often find high-fidelity components to tie together your hi-fi prototype experience. By taking advantage of component libraries, developers are often able to put together a polished, professional experience that can make or break a relationship with customers.

A stock image of a person working on UI/UX prototypes.
Image by William Iven from Pixabay

“Maybe it doesn’t have your particular brand feel to it, but you can still give someone what feels like a really slick professional experience. That kind of legitimizes what you’re presenting to them, which is especially important early on in a customer relationship when you’re setting those initial expectations about what they’re going to get.”

Fail Fast, Fail Often, but Remember to be Kind

With developers, particularly at startups, there can often be pressure between teams. Whether that’s tension between back-end and front-end teams on priorities or code quality–Or individual contributors making crucial documentation updates that are often undervalued–There exists a need to embrace the culture of failing fast and often, while still being kind and helping teammates to succeed. 

“There are software motivated ways to do that. So release notes, public mailing lists, Slack, et cetera, that allow you to make it clear when you’re making a trade-off or maybe sacrificing some quality for getting features in early. So, making sure to do that is really important and to the extent that you can, making that codified, right? A good example of this is if you’re writing a program in Go, you can have an internal package, which literally means this software can not be consumed from another package. So no one can depend on this software, but we’re going to use it internally. So that’s a great example of a very verbose codified signal that you can put out that this may not be something you want to rely on here.”

Remembering to be kind is another key tenant to working in open source communities. In some communities, non-code contributions are seen as ‘trivial,’ or are viewed as being, ‘less important,’ than other, code-heavy contributions. Magnum notes that while developers may not interact with one another beyond reviewing a pull request, it’s important to establish relationships with one another. This can help build and foster a welcoming open source community.

“One thing that I’ve found is really important is having good communication and that could look like brown bags or something like that. But when a designer, for instance, designs a new feature that needs to be implemented after an engineer implements that kind of like having a knowledge transfer of saying, “Hey, you don’t need to understand exactly what I did to implement this and I don’t necessarily need to know all the steps that went into the research to designing what this feature should look like, but let’s have a little bit of knowledge transfer to talk about what kind of effort goes into different things.” 

A stock image of chalk art on a sidewalk that reads, 'Be Kind'
Image by reneebigelow from Pixabay

In this Episode of The DroidDevCast:

01:18 – How Magnum approaches rapid prototyping
03:34 – Approaching rapid prototyping from a software architecture space
05:30 – Addressing how front-end and back-end developers approach production-ready code versus the overall quality of code
09:08 – Advice for getting code into production for startups
12:23 – Valuing the skillsets of all code contributors to a project
18:10 – Discussing Magnum’s career journey
23:44 – What Magnum would like to learn in the next year

You can read the full transcript of this interview on Simplecast. We’ll be back next week with another exciting episode, where we’ll be joined by A11y Project Maintainer Soren Hamby to discuss accessible UI and UX design. Be sure to like, subscribe, and listen to The DroidDevCast wherever you get your podcasts from.

Previous Episodes of The DroidDevCast:

Episode One: A Look Inside Esper with Yadhu Gopalan
Episode Two: Extreme Testing with Karthik Gaekwad

0