Welcome to the ProtoShare blog.

Feature Feedback Friday – Component Outline

We’re working to improve the ProtoShare Component Outline.  The Outline (highlighted below) lists all of the components on your page.  Using the Outline, you can select, re-order, access the context menu, and even drag from the Outline to move a component that is hard to select on the canvas.  Mousing over components in the Outline highlights them on the canvas.

ProtoShare Component Outline

ProtoShare Component Outline

 

The Changes

Current: Eyeball to toggle hide/show only when state attached to a component

Current
Attaching a “State” to a component (to hide or show it) causes an ‘eyeball’ icon to appear to the left of that element in the Outline. Clicking the eyeball changes States to show or hide the component.

New: All components have an eyeball to toggle hide/show. Components with states attached have a lightning bolt.

New
We’ve added an eyeball to every component in the Outline. Clicking the eyeball will hide or show that component. The icon for a component with a State attached changes to a lightning bolt.

The other change to the Outline involves identifying components that have Actions attached to them.  Actions in ProtoShare are events (like clicking or hovering on a component) that trigger States to change.  Today, the Outline does not show you which components have Actions.

New: Components with Actions attached show a hand icon to the right of the name.

New
Outline will display a ‘hand’ icon to the right of any component which has an Action attached.

We’ve written a 2 question survey for you to give us your thoughts, feelings and suggestions on these changes! (You can request a preview of the features too.)

Looking forward to hearing from you!

Posted in Uncategorized | Leave a comment

TechCrunch has a sense of humor

Really fun read:  http://techcrunch.com/2014/12/15/how-to-speak-startup/

TechCrunch needs to cover ProtoShare – we’re an actually profitable SaaS company, thanks to our fantastic, loyal customers.

Posted in Uncategorized | Leave a comment

Get Your Engineers Using ProtoShare

December has been a busy month for us – so we’re going to re-run an article that you may have missed.  You might want to forward this one to an engineer you know!

The majority of our customers are not software engineers. Instead, they are UX professionals, designers, business analysts, executives and project managers. We do have some effusive engineer customers, who are almost always part of a larger team using ProtoShare to reduce rework.

This post is an appeal to software engineers: Add prototyping to your toolkit. It will save you time, you’ll massively reduce rework, and you’ll end up a rockstar on your team.

We’re an agile shop. Our features start out as simple user stories. Our UX’ers will prototype, research, review and test implementations of user stories before they get packaged into a sprint. We don’t try to specify every last detail of a solution, we just try to get agreement on concepts, directions and limitations.

Often, fleshed-out user stories can go right to code. Fairly frequently though, issues arise early in a sprint: technology favors one implementation over another, unforeseen edge cases arise or other information is missing.

This is where prototyping as one of the arrows in a developers quiver can come to the rescue. Either by modifying someone else’s prototype, asking a question or building a prototype yourself, you can save time, reduce ambiguity and better satisfy your stakeholders.

For example, we wanted to expand our appearance bar to encompass all of the appearance settings supported by ProtoShare. We knew that some real estate would have to come from somewhere, but decided to leave some decisions up to the implementation team. After reviewing all of the information in the user story and associated prototypes, engineering realized there were at least three possible paths to completion, some involving significantly more work than others.

Knowing that any initial implementation would require revisions, and that even choosing the ‘quickest’ implementation still probably meant 2-3 days of wasted effort if it turned out to be wrong, the decision to invest 2-4 hours of time prototyping was a no brainer.

We ended up with three prototypes, and were able to have important stakeholders review these, look at them in context and choose the best path forward.

So why should engineers prototype? Because often, prototyping is overwhelmingly faster, and it’s the best way to communicate with and engage your stakeholders. Try it for yourself. Let us know how prototyping helps you as an engineer.

Posted in Blog, Prototyping Benefits | Leave a comment

Happy Thanksgiving!

Our offices will be closed November 27th and 28th for the Thanksgiving holiday. Standard customer service will be unavailable during this time. Our engineers will be monitoring for critical issues.

We hope you have a safe and happy holiday!

Posted in Blog | Leave a comment

Be the Brain with ProtoShare

I recently reread an interesting article by Jeff Gothelf about the assertion that Agile Development doesn’t have a brain. The most striking point in the article for me is that Agile teams don’t have a way to determine what features to build, whether they were the right ones, and whether they were built effectively.

Start prototyping

As a developer myself – I agree with that completely.  When I’m wearing my developer hat, I excel at answering the question “How can I do that?”.  I’m not so great at answering the question “Should I do that?” or “What else could I do?”.

In waterfall development, requirements come from a team dedicated to writing them, specifying them and preparing deliverables for development.  I’ve seen plenty of evidence that ‘requirements writers’ are experts and writing requirements, but not necessarily asking the questions Jeff posed above.

The best way to answer the “What should I do” question is to find out from the target users.  But there is a problem here too – they are no better in the abstract at answering the question than anyone else.  As Henry Ford said, if he listened to his customers he’d be building a faster horse.

The problem is that even users and potential users often don’t know what they want, or understand what’s being proposed, until they see and experience it.  But using prototyping tools like ProtoShare, you can create concrete experiences for users.  You can watch them struggle or succeed with your creation.  And you can iterate quickly until you accomplish your goals.

Even better – with a tool like ProtoShare, you can spread this experience to your entire team.  Everyone – from executives to developers to QA can use ProtoShare to experience and collaborate on creating better software solutions.  This is why some of our most successful customers start referring to ProtoShare as “the Brain” of their development processes.  ProtoShare becomes the repository of understanding for the entire team.

When you create a shared vision and a shared understanding among your team and your users, you’ll stop building the wrong features.  Want to answer the question of what you should build and how you should build it?  Use rapid prototyping to try a range of ideas, and hone it into a product that delights your users.

UX professionals are perfectly positioned to lead their teams and organizations to improving visualization practices, but anyone on the team, from executives to interns can contribute. Just start.  Crank out ideas and share them.  Your team will wonder how they ever did it any other way.

Posted in Uncategorized | Leave a comment