Persistent prototypes: how we build great products
By Michael Argentini
Managing Partner, Technology and Design
The way that we build great products is always evolving. And we've tailored the process to fit the needs of the varied clients (and industries) that represent our client base, as well as the way our creative teams want to execute.
The cornerstone of our development process is prototyping. And in the interest of transparency, we want to share a high-level view of how we do it, and what a typical development cycle looks like.
This article is focused on web applications, but the same principles apply to mobile and desktop apps. The only real difference is the toolset. Keep that in mind as you read further.
Whenever applicable (and possible), we prefer to build prototypes prior to developing a final product. These prototypes are maintained over time as a visual and interactive snapshot of what the user experience should be. And since they're maintained over the lifespan of a product, they're "persistent".
So why build them? Well, the following decalogue of benefits to this approach should answer that question. If you're like me, you'll be sold after the first few.
- ...facilitates an interactive design process, where clients and designers can see and interact with the product early on. This bootstraps the overall development cycle.
- ...gets your designers involved in a more meaningful and valuable way. They'll get out of Photoshop and Illustrator sooner. They'll think and design in code, which is also a training and personal development win.
- ...makes your developers more productive, since they're focused primarily on development, not markup.
- ...allows designers to focus on design and developers to focus on development. This also provides the freedom to use the best (and varied) tools.
- ...projects can very easily be hosted on a designer's workstation, no matter what operating system they use, which speeds up development.
- ...provides a playground for UI and interaction design experimentation and creativity, independent of a fully functioning product or platform.
- ...eases the transition from design and markup to final code.
- ...will provide a home for your style guide.
- ...enforces the use of a design pattern since it's a living, breathing website.
- ...helps maintain the integrity of a design when it's executed.
In the past, our process was more rigid. Once a design was sent over to the development team, it was mangled beyond recognition as part of the content management/delivery system integration process. And at that point, the UI or interaction designer had limited options for helping refine or evolve the product without significant assistance from the developers.
How We Build Them
The designers will host development prototypes on their workstations using different strategies, from virtualized Windows and IIS environments, to OS X with MAMP or customizing the built-in Apache configuration with virtual sites and local domains. After all, it's just a PHP website, so there are plenty of tools and hosting options that are easily used by the design team as they build.
We'll typically host the main prototype on our development servers in Amazon's EC2 environment for the client to see, and use a private Github repository for version control. You can add Git hooks to publish changes directly to the live prototype, which makes development even faster. This also facilitates communication with clients, since we will often use the Github issues system to track issues and resolutions.
The Development Cycle
We always prefer to work in an agile manner, and build as much as we can, as best we can, as time and budget allow. We will always exercise the right to turn a sharp corner midstream if we know it's the right decision. We don't stick to a rigid plan. We focus on goals and what we learn along the way.
That said, the start of a project and overall development cycle for the prototype look something like this:
1. Introduction and goal setting.
This is a meeting where we introduce the teams and lay out the project goals and expectations prior to a statement of work (SOW). Typically this time is billable after the SOW has been signed. We want to be on the same page regarding the goals. We want answers to the question: "What will define a successful project?"
2. Kickoff the project.
At this point, agreements have already been signed, and the budget and timeline have been identified. So the goals of the kickoff are to identify user stories and what the minimum viable product (MVP) will look like, so that we can sprint there as quickly as possible. We want to be able to get the basics nailed down and identify any gaps or gotchas as early as possible. This meeting is best held in-person or on a video conference.
We'll usually want to dig deeper into requirements at this stage. This includes initial research (either technical or subject matter). We generally do this independently, but will occasionally reach out to the client as-needed for guidance and clarification.
Before we start building the actual prototype, we need to create a rough content architecture. For some projects this is simply notes we write in Asana or Slack. For others, we may want to use a tool like Trello or for more complex products, a diagramming app like Visio or Omnigraffle. And there are even times that we jump right into a database server and start creating schema.
5. Start building the prototype.
We typically begin by creating a framework for the entire application (like scaffolding). This would use basic design elements (shapes and colors), and placeholder content; like an interactive wire. When appropriate, the client would provide feedback on the prototype using a tool like Github issues. We may assemble feedback into Trello as a Kanban board for assignment and prioritization.
6. One more pass.
After the initial pass, we iterate; digging deeper into the details. As with the previous step, all changes are deployed to a staging server for the client to see and comment on.
7. Communication and focus.
Throughout the process, we review progress with the client, and talk the product owner through the various UX decisions and discuss their business implications. This happens at least weekly. Once the biggest application design decisions have been made, we can proceed to design the user interface. But we're not there yet. And it's important to make sure the client knows what the focus is at this stage: UX and functionality.
8. User interface design.
Finally, the client will get to see the product adopt a design aesthetic and branding. By this point any client would be itching to see something that more closely represents the final product. Who could blame them? So we begin by creating an atomic pattern library(or style guide) for the product.
We then take the approved pattern library and integrate it into the prototype, requiring further conversation around design decisions, identifying what works, what doesn't, etc.
We continue to design, build, and test the prototype until we have a product that can be implemented in its host environment and platform. During this transition, we will often revisit the prototype for refinements, clarification, and confirmation.
When Are You Done?
Your goal is to create a prototype that feels like the product you want, but stops short with regard to content and functionality. You want to be able to take your atomic design and apply it to the product platform. You should want for nothing; every interface and design element you need should be available from the prototype. The design of the markup should be transferable. If you need a new feature or interface, you go back to the prototyping process, iterate, and integrate it into the platform.
The key to all this is that there should never be a grand unveiling. The client should always be pretty much up-to-date on what has been built so far, and where we're headed. In this way, budget is used as efficiently as possible, yielding the best quality and most robust feature set.
What do you think? Let us know using the form below.
Article last updated on 4/21/2018