In less than 10 hours, I turned an idea into a workable prototype that’s already in the hands of my customer.
Family-owned and operated farm located in Lebanon, New Jersey.
Fresh chickens are now for sale at the farm, but it is time-consuming for the family to manage multiple interactions with various customers throughout the day via cell, text, Facebook, etc. The family loves to interact with the members of their community, but in order to better serve their customers they hope to digitize some of the customer’s journey. The family understands what they need to build to improve their customer’s experience. However, it is too much of an undertaking to try to start a new project in addition to the mountain of work they already do on a daily basis.
I understand my client’s point of view. I understand their problem. As with most client requests, the business owner notices something about their model which is creating more work than necessary.
It is typically difficult for a family, or an individual, to source local natural food on a consistent basis. The farm hopes that by streamlining the purchase process for their customers it will create more access for their community to buy local. There is an opportunity to provide convenience, wellness, and access.
Frame the design challenge with a question
How might we make it easier for the farm’s community members to source their next dinner from Just Because Homestead?
For this project, baseline is today. Zero. The prototype I design will be the first iteration.
Launch a microsite within 24 hours that provides customers with a seamless experience. Continue to improve the site month-over-month by analyzing results, and utilize data to drive the priorities for the next iteration.
This is a two-day project. Day one is comprised of the following:
- Customer Research (120 minutes)
- speak with customer
- internet research
- observe online community to understand the habits, rituals, and shared vocabulary
- Competitive Analysis (60 minutes)
- what other companies or entrepreneurs are trying to solve the same problem?
- what services do competitors offer, if any, and how does each competitor position their brand as the solution to my customer’s problem?
- Opportunity Assessment (30 minutes)
- based on the research above, where is my greatest opportunity for success given the urgency to get something built and shipped to my customer as soon as possible?
- Define Tech Requirements (30 minutes)
- what do I need to build in order to capitalize on the opportunity?
- Low-Fidelity Rapid Prototyping (120 minutes)
- sketch initial thoughts on paper
- brainstorm using a mindmap to unpack the problem I’m solving
- outline my solution as it fits into the precise needs of this customer’s situation
- wireframe on paper what my solution might look like given the tech requirements listed above
To wrap up the first iteration of the prototype we finish day two with the following:
- High-Fidelity Rapid Prototyping of Visual Design (120 minutes)
- Custom WordPress Development (180 minutes)
- Quality Assurance QA (90 minutes)
Within 24 hours, we successfully launched the first iteration of the farm’s microsite.
Tracking empowers us to grow month-over-month
I installed Google Analytics on the site so that we have the activity to analyze at the end of each week. What’s working? What’s not working? How might we tweak the existing site to solve new customer problems as they arise? Using a free service such as Google Analytics provides my customer with the data they will need to modify and mold their microsite to meet the needs of the farm’s customers. Similar to how I meet the needs of the farm owners.
A list of things to keep in mind as you build a prototype, or start rapid prototyping:
- Work collaboratively with users, business and IT stakeholders while rapid prototyping. Apart from giving valuable feedback, they also gain a sense of ownership of the final product.
- Avoid “prototype creep” by setting expectations for the process, including ones affecting the purpose, fidelity, scope and duration. Remind everyone, including yourself, that rapid prototyping is a means to an end, not an end in itself.
- When creating interactive high-fidelity prototypes and simulations, build in realistic delays (for instance, for screen refreshing or moving through steps of a transaction), so that users do not expect instant response times from the final product.
- Reuse, reuse, reuse. For computer-based prototyping, this means saving reusable templates, stencils, patterns and widgets for future projects.
- Most importantly, begin every prototype review session with the disclaimer that this is just a prototype, a mock-up, not the actual solution. This reminds users that this is a work in progress, it encourages feedback, and in the case of high-fidelity prototypes, it prevents users from mistaking it for a working solution.
A list of things you should not do:
- Don’t prototype features or functionality that cannot be implemented—often an issue with software package implementations. When in doubt, confirm with developers before starting.
- Don’t take every change or request that comes out of a prototype review as a new requirement. Rapid prototyping helps capture missed requirements, but these new requirements should be evaluated carefully. Some may be implemented, while others are pushed to a future release.
- Don’t begin prototype review sessions without clear guidelines for feedback. Be very specific about the type of feedback you are looking for. (Are the steps logically arranged? Is the navigation clear and intuitive?) If not, be prepared for, “I don’t like the blue in the header,” or “Can’t we use this font instead?” or “Can you make this bigger, bolder, in red and flashing?”
- Don’t be a perfectionist. In most cases, rapid prototyping does not have to be 100% perfect, just good enough to give everyone a common understanding.
- Don’t prototype everything. Most of the time, you shouldn’t have to.
One more batch of resources: