I'd speculate that if this review were done in 6 months, Balsamiq would be the hands down winner given the writer's criteria.
The balsamiq team is working on a new project: myBalsamiq https://www.mybalsamiq.com/ . It looks like it will make both sharing and collaboration dead easy. You can even get a sneak preview of how the Balsamiq team are using it. https://our.mybalsamiq.com/projects/
I'm the author of the post. I did actually come across their comparison table, which states that a web app is in the works, just I totally forgot to mention that in the post. I just played around with the project you linked to though and I must say, it is pretty amazing. Depending on the pricing scheme they end up with, I would definitely reconsider my choice.
Drop box solves the collaboration problems with any program. We used balsamiq mockups and were incredibly pleased with it. The sharing and collaboration was a bit difficult, but DropBox solved that problem completely.
I must be getting old and curmudgeonly because yesterday I was arguing against CRM in favor of spreadsheets and today I'm arguing against mockup tools in favor of pen and paper...
Again: we tried several tools including Balsamiq, Mockingbird, Photoshop, PowerPoint, Keynote, and others. Ultimately, what worked best was a combination of a whiteboard and paper.
1) Gather a few team members in a meeting room
2) Give each person their own color marker
3) Go nuts on the whiteboard, draw whatever comes to mind.
4) Make lots of revisions. This is the best part: It's a whiteboard! Erase with your finger. Get over it, get dirty, mix colors, make a mess. Who cares?
5) When you're ready, let your best "artist" redraw it on the whiteboard nice and big so everyone can make even more revisions.
6) On paper or a laptop or whatever, take notes of any edge cases or things you simply didn't think of earlier.
7) Repeat 3 to 6 until you're happy.
8) Transcribe to paper. This is vital! Do not just take a photo. You need to have every single screen on it's own piece of paper, so you can thumb through them later.
9) Write the name of the screen on the top edge of the back of the page. This is so you can quickly skim through the stack backwards to find the page you are looking for.
10) Write any notes about the behavior of the page on the front as callouts or on the back as commentary.
11) Photocopy the whole stack and hand out to the team.
12) Encourage everyone else to write all over them in red pen
13) Bring the notes to the next meeting & start all over until it's close enough to go to implementation.
Note: this advice is for NEW UIs. I still haven't quite figured out the best way to handle changes to EXISTING UIs. There seems to be a mismatch in our brains when you try to draw stuff on top of print outs of real screens. The resulting markups look out of place next to polished features, so they don't get the same thought process as a completely hand drawn mockup. I've got to do more experimentation here...
You could call that advice old and curmudgeonly, I suppose. You could also call it lightweight and agile, and still be right. That's the power of marketing!
(Seriously though, I think this is a good approach, and thank you for putting it so clearly.)
Maybe I should write a book, title it "Lightweight Agile Engineering By A Not So Old, But Still Quite Curmudgeonly, Hotshot Full-Stack Developer, Ninja Rockstar"
In addition to the chapters "Spreadsheets Are Pretty Much Always Better Than Writing Code" and "Love Thy Whiteboard", there could be chapters titled "How I Learned To Stop Worrying And Love The Command Line", "Visual Debuggers Are For People Who Can't Read", "Big Oh-My-God It's Not That Hard", and "Seriously Guys, Someone Already Did That Way Better".
I had the same thoughts initially and initially I started making my mockups for this project on pen and paper. I quickly ran into two problems though:
1) My client is in CA and I'm in NYC - the only way to get them my pen and paper mockups is to scan each individually and e-mail them.
2) My clients had a lot of feedback on the designs and over a couple of hours, we went through a dozen different versions of the mockup. Doing this with someone far away is far more difficult than using an app that lets you drag and rearrange elements on the fly.
I still agree with your process if everyone is located in the same area but for remote works, I don't think it's a viable option.
Really? I've never had success with a "design by committee" approach. For me, it's always worked best to have one person work on a few screens, pull everyone into a room, beat it up, then send them back to fix it up. Repeat a few times.
Meaning: one author, lots of feedback. The author owns the design.
I've been really impressed with LucidChart recently. I'm on a trial account and will probably sign up. It's not limited or specifically focused on wireframing, it's something closer to a lightweight OmniGraffle or Visio.
12 comments
[ 3.3 ms ] story [ 17.6 ms ] threadThe balsamiq team is working on a new project: myBalsamiq https://www.mybalsamiq.com/ . It looks like it will make both sharing and collaboration dead easy. You can even get a sneak preview of how the Balsamiq team are using it. https://our.mybalsamiq.com/projects/
Re: pricing, here's what we're thinking: http://www.balsamiq.com/buy?p=myb
(eagerly waiting...)
Again: we tried several tools including Balsamiq, Mockingbird, Photoshop, PowerPoint, Keynote, and others. Ultimately, what worked best was a combination of a whiteboard and paper.
1) Gather a few team members in a meeting room
2) Give each person their own color marker
3) Go nuts on the whiteboard, draw whatever comes to mind.
4) Make lots of revisions. This is the best part: It's a whiteboard! Erase with your finger. Get over it, get dirty, mix colors, make a mess. Who cares?
5) When you're ready, let your best "artist" redraw it on the whiteboard nice and big so everyone can make even more revisions.
6) On paper or a laptop or whatever, take notes of any edge cases or things you simply didn't think of earlier.
7) Repeat 3 to 6 until you're happy.
8) Transcribe to paper. This is vital! Do not just take a photo. You need to have every single screen on it's own piece of paper, so you can thumb through them later.
9) Write the name of the screen on the top edge of the back of the page. This is so you can quickly skim through the stack backwards to find the page you are looking for.
10) Write any notes about the behavior of the page on the front as callouts or on the back as commentary.
11) Photocopy the whole stack and hand out to the team.
12) Encourage everyone else to write all over them in red pen
13) Bring the notes to the next meeting & start all over until it's close enough to go to implementation.
Note: this advice is for NEW UIs. I still haven't quite figured out the best way to handle changes to EXISTING UIs. There seems to be a mismatch in our brains when you try to draw stuff on top of print outs of real screens. The resulting markups look out of place next to polished features, so they don't get the same thought process as a completely hand drawn mockup. I've got to do more experimentation here...
(Seriously though, I think this is a good approach, and thank you for putting it so clearly.)
In addition to the chapters "Spreadsheets Are Pretty Much Always Better Than Writing Code" and "Love Thy Whiteboard", there could be chapters titled "How I Learned To Stop Worrying And Love The Command Line", "Visual Debuggers Are For People Who Can't Read", "Big Oh-My-God It's Not That Hard", and "Seriously Guys, Someone Already Did That Way Better".
1) My client is in CA and I'm in NYC - the only way to get them my pen and paper mockups is to scan each individually and e-mail them.
2) My clients had a lot of feedback on the designs and over a couple of hours, we went through a dozen different versions of the mockup. Doing this with someone far away is far more difficult than using an app that lets you drag and rearrange elements on the fly.
I still agree with your process if everyone is located in the same area but for remote works, I don't think it's a viable option.
Meaning: one author, lots of feedback. The author owns the design.