Prototype Development at STRIVR

After doing the initial development for STRIVR Player and STRIVR Creator, I took a role on the design team as the VR Prototype Developer, where I worked with the designers, engineers, and content creators to develop new features for our products. In this role, I worked with leadership and the various teams to define our prototyping and handoff processes.

One of my favorite features we developed was a way to handle spoken branching conversations in our conversation training tool, without using natural language processing. The most obvious solution was a Mass-Effect-like “What do you want to say? A or B” menu, but because of our specific needs and goals, the best solution ended up being a design that didn’t prompt the user in any way, to force the user to come up with the appropriate response on their own, using their own words. That way, the user was forced to reflect on their own learnings and have an organic and realistic response to the avatar, rather than being primed by a set of potential responses ahead of time.

When developing a new feature, I start by listening to the stakeholders and delving as deep as I can into the requirements and need. Why do the stakeholders want this feature? Are the stakeholders I meet initially the correct persona? Will the feature being suggested solve the underlying need, or is there a better way to address it? Often, I discover that the requested feature is not the best way to address the underlying need, and we will redefine the User Story to better reflect the underlying need.

After gaining a close understanding of the need, I work with a designer to brainstorm and come up with different ways to address the need. Sometimes the most obvious solution is the correct one, but sometimes exploration will yield a better, less obvious solution.

After paper prototyping and storyboarding, I’ll eventually build 2 or 3 first pass prototypes that we can test internally. After a few weeks of revision, demonstrations with stakeholders, and user testing, we’ll agree on what the feature should look and feel like, and I’ll make a final prototype that I test with proper outside testers of the appropriate persona type.

After one more round of revisions, I present a final report to the stakeholders and engineering team, and submit a document describing the feature. This includes an executable, the prototype feature branch, and any notes I have about the implementation, edge cases, etcetera. I then work with the engineering team as they implement the feature and ultimately push it out in an upcoming release.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s