Use What You Need to Get Your Message Across

Kyle Adamo published an article today over at UX Booth about integrating Google Charts in your prototypes to deliver a high-fidelity experience. Not something you would need to do all the time, but very useful when you do. Here’s how you can do this in ProtoShare.

From a Google Spreadsheet where you have a chart, you can select to publish an interactive chart or image. The interactive chart gives you a script block to paste into HTML (the ProtoShare Advanced HTML component for instance), and the image option gives you the URL of an image, which you can use in an Image Component in ProtoShare. Then wire up the charts with some states and a state Jump Menu and you’ve got the bare bones of the same widget. The video below shows the details. Sorry, no sound. I just did it quick this morning.

Let’s examine Adamo’s article a bit more. My first reaction, and I’m sure the reaction many UX professionals might have, was that this was an awful lot of trouble to go to for a protoype. Seems like this level of detail shouldn’t be necessary. It’s even possible that the functionality is overbuilt and the developers will have difficulty implementing it.

But Adamo addresses this in the article. He states that he knows his audience and his developers. Prototypes are used to convey concepts and generate discussion so decisions can be made. The high level of interactivity was needed for his stakeholders. If he had done less he would have wasted everyone’s time by trying to gain insights with insufficient information.

So for me the two big takeaways from this article are:

  • Prototypes exist to drive communication so you can make decisions. Do what you need to make sure you are engaging your stakeholders to get answers to the questions you have.
  • Use whatever you need to build your prototype. This might mean going outside your prototyping application. If you can quickly build a chart in Google spreadsheets and include it through an iframe or image, do that instead of spending lots of time building a chart with basic shapes.

Overall a good article on a creative technique used to quickly deliver what stakeholders needed to have an informed discussion. Well done, Kyle.

Have you ever incorporated external tools into your prototypes? If so, we’d love to hear about it in the comments.

Posted in ProtoShare Tips, Prototyping Benefits | Leave a comment

Free Yourself From Documentation

I came across an interesting post by 37signals about eliminating documentation from the development process.

A quick excerpt:

“It looks like a dilemma. You either:

  1. Produce design ideas at the pace of development (which is far slower, by definition of the bottleneck) or
  2. Freeze ideas in the form of documents, diagrams and requirements until they are ready to be thawed and consumed later.

I suspect #2 is what happens in a lot of firms. The throughput from design to implementation in those places is so low that pacing design with development doesn’t seem feasible.

At 37signals we’re firmly in the #1 camp. Designs go from concept to HTML (often in-app) without any deliverables in-between, and then from HTML mock to fully implemented feature in Ruby or JavaScript again without intermediate artifacts.”

In general, I agree; documentation is ‘frozen’ and can quickly go bad. But I don’t like tying everything to the pace of development, and here’s why:  Sometimes during the design phase, I identify things that I don’t want to do. Or I change my mind about the business value of particular features. I certainly don’t ever want my developers to have to wait to have design finished. If design is tightly coupled to development, my developers are  implementing ideas that are not fully formed, fully explored or understood. This, in and of itself, will slow development. If you have a problem with implementation throughput, that may simply reflect a design problem, not an implementor issue.

For me, ProtoShare provides teams with an Option 3:  Allow designers, UX’ers and business stakeholders to do some of the work that 37signals gives to their developers:  figure out what really works through prototyping. So instead of building ready-to-eat frozen specs, you actually experiment, iterate and evolve your ideas. You assess business value more realistically than without a simulation, so that when your developers are ready to build, they are building your best ideas – with the highest business value.

One other reason I love ProtoShare – it allows your designers, UX’ers and business stakeholders to focus on the work. Your team can be creative, experimental and innovative. ProtoShare handles the documentation for you. All of your ideas, discussions, thought processes and end results are all available within a single repository. Your developers can reference prototypes, creative and discussions – the true source material of your design process. This is why some of our customers have called ProtoShare the ‘brain’ of their development processes.

So this is what I agree with in the 37signals article:  Less documentation can mean more productivity. Documented solutions quickly go stale. What I don’t agree with: slow everything to the pace of development. Instead, use ProtoShare to accomplish some of the design tasks that slow development:  experimentation, iteration, exploration. You’ll end up with better products, make the right decisions about what features to develop, and you’ll speed up your development process through clearer specifications, improved communication and reduced rework.

Posted in Industry, Prototyping Benefits | Leave a comment

Introducing ProtoShare 6

Because Discussions Need Decisions

We’re releasing ProtoShare 6.0 today, and I want to share with you why I’m so excited about it.  Nearly a year ago we released version 5.0, which changed the way we prototyped. But the changes we made to this release have really transformed our use of ProtoShare, and we hope they’ll transform your usage as well.

ProtoShare has supported collaboration since version 1.0.  We’ve always viewed collaboration and sharing as critical to the process of prototyping and wireframing.  Over the years, we’ve had many requests for enhancements and better defined workflows. ProtoShare 6.0′s biggest feature is a vastly improved Review system.

As we worked with review, we came to think of ProtoShare as more of a decision engine than just a prototyping tool.  Our initial Review was very free-form and egalitarian.  Everyone could leave comments.  Everyone could see all comments.  Everyone got emails from every comment.   There are some things we still like about this model – one key to ProtoShare is engagement, and this got everyone engaged.  This model starts to break down when you have lots of collaborators, lots of comments, or both.

Some of the questions we wanted to answer for our users:
“What should I pay attention to in ProtoShare?”
“What decisions were made from this topic?”
“When is the discussion done?”

Here is how we addressed these:

  1. What should I pay attention to in ProtoShare?

    We added three features to support this

    1. Read/Unread status topics across the entire project.  When you log into ProtoShare, you now see an indicator on any topic that you haven’t read, or that has new replies or status changes since you last read it.  Much like an email inbox, the things you haven’t seen are marked as unread.
    2. Topic Subscription.  In previous versions of ProtoShare, all project members see and get notifications for all topics.  In Version 6, topic creators can choose a subset of ‘Subscribers’ to receive notifications.  This reduces the number of discussions that you will have to deal with. If its important for you to see, you will be subscribed to the topic.
    3. Topic Ownership.  While we did away with the ‘Assignment’ feature of ProtoShare topics, we added the ability to assign ‘Ownership’.  A topic can be owned by one or more subscribers.  By default, you are the sole owner of topics that you create.  You can add more owners or change this later on.  On the project dashboard, or in review, you can view only your ‘owned’ topics.  If one project member’s feedback is critical, you can make that person an ‘owner’ of a topic, bringing the item to that person’s attention.
  2. What Decisions were made from this topic?

    To address this, we added the ability to mark one or more topic replies as a ‘Decision’. Topics with decisions are flagged, and decisions rise to the top of the topic for easy viewing. Notification emails are also sent when decisions are made.

  3. When is the discussion done?

    To address this, we replaced the ‘To-do’ status of topics with ‘Resolved’.  When you mark a topic as resolved, it is flagged as resolved, and no more commenting on the topic is allowed.  The topic will still show up on your prototype until you archive the topic.

These features together really help to provide a very useful review workflow.  Users see what they need to see, discussions happen and decisions are made.  When topics are resolved, they are available for stakeholders to see the resolution.  What we and our early testers have found is that ProtoShare becomes the go-to tool for managing feedback.  It’s simple, useful and keeps your project progressing, which is really the purpose of wireframing and prototyping.

These features also make the ‘clickable comp’ workflow, the review of Photoshop comps, discussions around live sites using ProtoShare live-views and many other functions much more productive.  We’re convinced that ProtoShare 6 will improve the way you work, and help you to collaborate more effectively.

We’ve talked about how sometimes free-form collaboration starts to feel like ‘design by committee’.  With the more structured collaboration in ProtoShare 6, you’ll get the benefits of getting all of your stakeholders pulling in the right direction, decisions getting made, issues being resolved and your projects moving forward faster than ever before.

ProtoShare 6 has quite a few other nice enhancements.  Find out more about them and all of the new features in our release notes.

As always, let us know what you think, and tell us what else you’d like to see in ProtoShare.

Posted in ProtoShare.com, Releases | Leave a comment

Happy Holidays from the ProtoShare Team!

We would like to wish all of our customers, friends, and families a happy and healthy holiday season.

We particularly want to express our deep appreciation to our customers for your continued support, encouragement and advice. Providing a product that matters to our customers is the reason we’re here.

The end of the year has been as busy at ProtoShare as it has been at the North Pole. We’re preparing for the launch of our new release, ProtoShare 6, ready to be delivered shortly after the New Year.

Customers understand the power of collaborative prototyping and have seen their processes transform with short, iterative prototyping sprints to uncover project requirements. Many of you have also shared with us how ProtoShare has become the “brain” or hub of your product development. Now ProtoShare 6 will take collaborative prototyping to the next level.

We look forward to sharing the new version with you soon.  We’re excited to get your feedback.

Thanks so much for your support.  Here’s to an exciting and productive 2012!

Posted in Business | Leave a comment

Neil Gaiman on Feedback & Perfection

From Gotham Writers’ Workshop, celebrated author Neil Gaiman lists good writing practices – a couple of which apply nicely to prototyping with ProtoShare.

5. Remember: when people tell you something’s wrong or doesn’t work for them, they are almost always right. When they tell you exactly what they think is wrong and how to fix it, they are almost always wrong.

When soliciting feedback, ask for it in ways that help your reviewers tell you what feeling they get when they see or interact with the prototype. Does it flow well? Is it confusing? Does it seem to take up too much time? These kinds of questions help increase the chance of getting feedback you can use, instead of specific comments on font selection and color choices.

Likewise, when giving feedback, do the same. Think about the overall feel of a web prototype and try to highlight areas where you get confused or frustrated and explain why. At this stage don’t worry about how to fix.

6. Fix it. Remember that, sooner or later, before it ever reaches perfection, you will have to let it go and move on and start to write the next thing. Perfection is like chasing the horizon. Keep moving.

Words to live by. A prototype can always be better. Or at least be different. Getting something done is the most important thing. After all, you want to actually build what you’ve been prototyping. Make sure you prototype just enough to communicate your ideas so you can gain buy-in and not over-prototype. It’s much better to have buy-in across many aspects of the project, with some details left to fill in, than it is to have one small area meticulously envisioned.

Posted in Prototyping Benefits | Leave a comment