View
349
Download
0
Category
Preview:
Citation preview
Isle of Code• Toronto based development;
• Focused on:
• Prototyping;
• Single sourcing mobile /w Ember.js & Phonegap;
• Using Canvas /w Ember; and
• A lot of beacon work lately.
Agenda• A little on prototyping;
• Iters 1-5 of a prototype we built;
Why
Test & iterate on product ideas cheaply
Align teams around simple ideas
Tour new product ideas to stakeholders and potential clients
Expose product weaknesses before starting a long build
Learnings from iterations often lead to small but critical changes in design and feature set
Expose budget issues early
Speed final development
Common Problems
Proposed product does not work as theorized
Stakeholders do not have the interest perceived in the proposed product
The technology solution is harder to achieve than theorized
Not enough data for valid testing of use case / product idea
Technology is slower than imagination
Customers / Users like the product, but do not value it enough to change their habits or buying behaviour
Frameworks• Our goal is to mock the core ideas of an app, and not to be distracted with utility and
hygiene functions (e.g. user registration and login);
• Some characteristics we look for:• Distinction between back-end and front-end concerns;• Ability to mock API responses, preferably without even having a backend (Fixtures);
• Avoid considering utility as long as possible. Ember Data uses RESTful conventions & has Fixtures;
• Components - we’ll be throwing things around;• As few dependencies as possible (moving fast); • As multi platform as possible;• Simply having a framework matters, because convention matters.
3 Main Steps1. Ideation2. Low-fidelity Wireframes3. Software Prototype Iterations
Iterating from here• Two types of products:
• idea and use case is very well known upfront (e.g. specific internal tool);
• idea has no product/market fit.
• When the idea is known, we generally prefer to spend longer coming up with high fidelity wireframes before programming.
• When the idea is less known, we find it easier to sketch with technology. Good tech evolves from many iterations, and longer windows of poking it with a stick.
• e.g. the first iteration of Unread was actually for desktop, before we realized this was a bad idea.
unread
unread thesis• An app which parsed our email activity, and reminded us
of:
• People we forgot to respond to in the past week, or who forgot to respond to us; and
• People we had not spoken to for > 3 months.
• We thought this would be a good idea.
• We’d already built email parsers before, so we had no concerns about whether the backend was possible/feasible.
Low Fi Frames● Ensure global product understanding;
● Provide developers with a simple representation of the product and its goals, without conflicting statements
● An early attempt to expose any critical weaknesses
Iter 1 (1-2 days)• Main init (routes, Contact model, Fixtures);
• We were imagining a drag and drop interface, so decided to focus here;
• We realized there were 3 main actions (vs. 2 - we added hide);
• Not worried about too much else.
The very first version
Iter 2 - real data!• Iter 1 was not pretty but mostly worked. We dropped
drag and drop in favour of the fast contact buttons;
• In Iter 2, we could have started making the app look better, but is this even a good idea?
• Live data is good to expose common ui/ux issues;
• Fake data lets you keep cheating;
• Showing fake data today for privacy.
Iter 3• With new animations, unread was closer to what we wanted, so:
• Add multiple email accounts;
• Fix nav bar;
• Add actual user accounts!
• We discovered contacts.index was a better way to view, especially once many email accounts were involved.
• And on the back end, tried out graph databases / optimized SQL
Iter 4: Improve Index• Focusing on contacts.index was the right idea;
• Everything works and is stable. Make it look like a ‘mostly finished prototype’;
• Add shortcut actions to the index with gestures, e.g. swipe left and right;
• Pay back technical debt, e.g.
• ListView
• Bounce Scroll
• Cut a release.
Iter 5: Drag was slow• Choppy and deal breaking. This is common when
working with DOM;
• Need to move to Canvas;
• ~16ms target for animations, DOM can’t do this;
• Conceptually unread was stable, so invest the extra time.
Iter 6: Add Paint
After 6 iterations• What is left?
• Finish app/buttons
• Production-ize backend
• Actual designer
Building better products by forcing evolution on iterations, vs. detached documents
Many initial assumptions were wrong (e.g. Tinder style vs. index)
A lot of hurdles discovered and cleared up front (e.g. multi email scenarios)
We gradually built more performant technology as needed (e.g. Swipe), and didn’t need to throw much out (e.g. optimizing drag and drop)
Recommended