7 ms·

From idea to core prototype in hours, not weeks

29 points by williamnewton 13y ago

iterable 13y ago
nice
- deleted 13y ago
  [deleted]
  - deleted 13y ago
    [deleted]
trekky1700 13y ago
Nice job, though you could argue a big part of the prototyping (in fact, the main feature) was already completed. Most of the design decisions, illustration and how the information should be displayed had already been 90% provided by Neila.
- williamnewton 13y ago
  That's accurate, and I think that's all the more reason to jump in and start. The content is all there, but there's more detail needed to make an app like this awesome, including stats and UX polish. I'm advocating for the 'just start' approach.
  - trekky1700 13y ago
    Indeed, the "just start" approach is awesome. It cuts the excuses people find to continue to "prepare" or procrastinate.
seanmcdirmid 13y ago
I'm a bit confused by the article's blurring of design and prototyping boundaries. Is it reasonable (i.e. useful) to convolute wire framing with prototyping? I once worked as a prototyper for a design studio, and to them prototype meant an approximation of the product that could be used for critique and evaluation with users (so maybe a lofi paper prototype, deck-like click-thru prototype, or even a quick/dirty application).
- williamnewton 13y ago
  Is it not clear that my approach is to 1. map out the idea (wireframing) and then 2. hack together a prototype?
  - seanmcdirmid 13y ago
    Your post mixes together wireframing with prototype hacking. But I guess this is to be expected when programmers are doing design, a designer would look at this very differently.
    - jbeja 13y ago
      Agree.
bobbygoodlatte 13y ago
I too am a fan of rapid prototyping, but the example app here is incredibly simple. More complex apps require more time to refine & prototype. That said, this sort of flat prototype should be do-able in a few days for even the largest of apps. So, I'm in agreement with OP — except on the timeframe :)
- deleted 13y ago
  [deleted]
jbeja 13y ago
IMHO, I don't know why people keep confusing UI with UX like they are the same thing, do you actually design the "UX" base on your own intuition without even know or test what the audience you are targeting for the specific product?. This more a wire framing to me, since this "prototype" is far from finish. I wait to read the next chapter since you it seems that it will address some of my concerns above :). Cheers
- williamnewton 13y ago
  Exactly — start with intuition then get feedback and fix what you were wrong about. And it's definitely far from finished. Thanks!
pcurve 13y ago
I think this is how most people work, unless you're a consultant that get paid by the amount of deliverables you produce. :-) Prototyping to solve problems is often the quickest. Pulling other people's teeth to reach that point is what takes weeks. :-)
deleted 13y ago
[deleted]
avoiceandname 13y ago
I completely agree with your last point on getting feedback and iterating on your designs. Prototyping is such an important part of the design process. ABP (always be prototyping.) I wanted a prototyping solution that worked within a designer's existing workflow which is why we built Stand In [http://standin.io http://standin.io] on top of Photoshop. It allows us to keep the prototype always in sync with the design and truly becomes part of the design process — not just a step afterwards.
- williamnewton 13y ago
  I would use Standin if I used Adobe CC. Nicely done.
thatthatis 13y ago
Mockup. This guy is talking about building mockups, and only mockups. A prototype is a working version of all key features that can be used as if it were the final product albeit in a somewhat limited fashion (E.g. the edges aren't rounded) A mockup demonstrates the value in a non-working fashion so people can respond to the general idea. If you don't get mockup vs prototype right, it's pretty hard for me to value your opinion on these matters.
- williamnewton 13y ago
  This post is talking about prototypes from a usability perspective, not a technical perspective. A prototype by your definition ( a "real" prototype) would use data and be built in about the same way as the final product would be. I'm talking about how to prototype the experience. I see how it's easy for you to misunderstand me - apologies for not being clear.
  - deleted 13y ago
    [deleted]
  - thatthatis 13y ago
    Then it would be helpful if you qualify prototype as "ux prototype" or "interaction prototype". Paper prototypes, which this is fairly similar to, is a term that is lexically unambiguous. Without the qualification the title becomes confusing. I initially thought you were claiming to have a methodology to get a "real" non trivial prototype in a few hours.
- mrxd 13y ago
  That's not how its used in UX design. A mockup is essentially a screenshot: non-interactive, visually accurate. A prototype is an interactive simulation of the system. The term encompasses simulations which are very far from the final product, like creating interfaces using hand-drawn pieces of paper and sticky notes which are operated by a human acting as the system. I find that it's helpful to evaluate ideas on their merits instead of quibbling over terminology.
  - 13y ago
nswanberg 13y ago
This is a great post, but in these comments there is a strange fixation on the terminology. Is it really a mockup? Is the author describing an interface or an experience? None of these comments really say why the distinction is more important than the point of the post, which is to get an idea in front of users. But if the obsession over the term is forcing you to ignore the point of this post, possibly this will help: a guy at Google apparently decided that the distinction was enough to coin the word "pretotyping": http://www.scribd.com/doc/62418833/Pretotype-It-Second-Pretotype-Edition#page=23 http://www.scribd.com/doc/62418833/Pretotype-It-Second-Preto... (Even if the terminology doesn't matter to you, skim the book--it's free here and has got some great ideas).
gotofritz 13y ago
I worked in a large, supposedly ground breaking digital agency where we had a game manufacturer as client. The client were keen on agile and continuos prototyping / mockups. Sadly the designers (pardon, 'creatives') and ux didn't want to know, the were too set in their ways and couldn't get out of the old workflow: work Photoshop / OmniGraffle; refine until perfect; pass on to developer. Eventually the client got pissed off and we lost them. The visual people just couldn't get their head around not having complete perfection at each step of the way. Shame, because it was a great project.
- Dwolb 13y ago
  This resonates pretty well with me due to my current role in an organization. Did anyone own the execution side of the project to hold the designers accountable for late deliverables?
  - gotofritz 13y ago
    Of course not, it was a creative agency, our job as developers was to cater to every creative's wish

29 points by williamnewton 13y ago

iterable 13y ago

nice

deleted 13y ago
[deleted]
- deleted 13y ago
  [deleted]

trekky1700 13y ago

Nice job, though you could argue a big part of the prototyping (in fact, the main feature) was already completed. Most of the design decisions, illustration and how the information should be displayed had already been 90% provided by Neila.

williamnewton 13y ago
That's accurate, and I think that's all the more reason to jump in and start. The content is all there, but there's more detail needed to make an app like this awesome, including stats and UX polish. I'm advocating for the 'just start' approach.
- trekky1700 13y ago
  Indeed, the "just start" approach is awesome. It cuts the excuses people find to continue to "prepare" or procrastinate.

seanmcdirmid 13y ago

I'm a bit confused by the article's blurring of design and prototyping boundaries. Is it reasonable (i.e. useful) to convolute wire framing with prototyping? I once worked as a prototyper for a design studio, and to them prototype meant an approximation of the product that could be used for critique and evaluation with users (so maybe a lofi paper prototype, deck-like click-thru prototype, or even a quick/dirty application).

williamnewton 13y ago
Is it not clear that my approach is to 1. map out the idea (wireframing) and then 2. hack together a prototype?
- seanmcdirmid 13y ago
  Your post mixes together wireframing with prototype hacking. But I guess this is to be expected when programmers are doing design, a designer would look at this very differently.
  - jbeja 13y ago
    Agree.

bobbygoodlatte 13y ago

I too am a fan of rapid prototyping, but the example app here is incredibly simple. More complex apps require more time to refine & prototype. That said, this sort of flat prototype should be do-able in a few days for even the largest of apps. So, I'm in agreement with OP — except on the timeframe :)

deleted 13y ago
[deleted]

jbeja 13y ago

IMHO, I don't know why people keep confusing UI with UX like they are the same thing, do you actually design the "UX" base on your own intuition without even know or test what the audience you are targeting for the specific product?. This more a wire framing to me, since this "prototype" is far from finish. I wait to read the next chapter since you it seems that it will address some of my concerns above :). Cheers

williamnewton 13y ago
Exactly — start with intuition then get feedback and fix what you were wrong about. And it's definitely far from finished. Thanks!

pcurve 13y ago

I think this is how most people work, unless you're a consultant that get paid by the amount of deliverables you produce. :-) Prototyping to solve problems is often the quickest. Pulling other people's teeth to reach that point is what takes weeks. :-)

deleted 13y ago

[deleted]

avoiceandname 13y ago

I completely agree with your last point on getting feedback and iterating on your designs. Prototyping is such an important part of the design process. ABP (always be prototyping.) I wanted a prototyping solution that worked within a designer's existing workflow which is why we built Stand In [http://standin.io http://standin.io] on top of Photoshop. It allows us to keep the prototype always in sync with the design and truly becomes part of the design process — not just a step afterwards.

williamnewton 13y ago
I would use Standin if I used Adobe CC. Nicely done.

thatthatis 13y ago

Mockup. This guy is talking about building mockups, and only mockups. A prototype is a working version of all key features that can be used as if it were the final product albeit in a somewhat limited fashion (E.g. the edges aren't rounded) A mockup demonstrates the value in a non-working fashion so people can respond to the general idea. If you don't get mockup vs prototype right, it's pretty hard for me to value your opinion on these matters.

williamnewton 13y ago
This post is talking about prototypes from a usability perspective, not a technical perspective. A prototype by your definition ( a "real" prototype) would use data and be built in about the same way as the final product would be. I'm talking about how to prototype the experience. I see how it's easy for you to misunderstand me - apologies for not being clear.
- deleted 13y ago
  [deleted]
- thatthatis 13y ago
  Then it would be helpful if you qualify prototype as "ux prototype" or "interaction prototype". Paper prototypes, which this is fairly similar to, is a term that is lexically unambiguous. Without the qualification the title becomes confusing. I initially thought you were claiming to have a methodology to get a "real" non trivial prototype in a few hours.
mrxd 13y ago
That's not how its used in UX design. A mockup is essentially a screenshot: non-interactive, visually accurate. A prototype is an interactive simulation of the system. The term encompasses simulations which are very far from the final product, like creating interfaces using hand-drawn pieces of paper and sticky notes which are operated by a human acting as the system. I find that it's helpful to evaluate ideas on their merits instead of quibbling over terminology.
- 13y ago

nswanberg 13y ago

This is a great post, but in these comments there is a strange fixation on the terminology. Is it really a mockup? Is the author describing an interface or an experience? None of these comments really say why the distinction is more important than the point of the post, which is to get an idea in front of users. But if the obsession over the term is forcing you to ignore the point of this post, possibly this will help: a guy at Google apparently decided that the distinction was enough to coin the word "pretotyping": http://www.scribd.com/doc/62418833/Pretotype-It-Second-Pretotype-Edition#page=23 http://www.scribd.com/doc/62418833/Pretotype-It-Second-Preto... (Even if the terminology doesn't matter to you, skim the book--it's free here and has got some great ideas).

gotofritz 13y ago

I worked in a large, supposedly ground breaking digital agency where we had a game manufacturer as client. The client were keen on agile and continuos prototyping / mockups. Sadly the designers (pardon, 'creatives') and ux didn't want to know, the were too set in their ways and couldn't get out of the old workflow: work Photoshop / OmniGraffle; refine until perfect; pass on to developer. Eventually the client got pissed off and we lost them. The visual people just couldn't get their head around not having complete perfection at each step of the way. Shame, because it was a great project.

Dwolb 13y ago
This resonates pretty well with me due to my current role in an organization. Did anyone own the execution side of the project to hold the designers accountable for late deliverables?
- gotofritz 13y ago
  Of course not, it was a creative agency, our job as developers was to cater to every creative's wish