Using Prototypes for more than just user-testing

Question

Other than for user-testing purposes, PM, Dev and QA are asking the designers in our company to create prototypes to be used as a guide along side of annotated wireframes and visual specs and the actual stories.

In a perfect agile world this may work, but being a shared resource designers, it doesn't seem feasible.

Other disadvantages I see include, needing to fully built out every single interaction in the prototype. Also, Dev and QA can easily miss interactions since there are no specs in the wireframe calling out specific logic or interactions.

Are there any designers out there efficiently providing prototypes as deliverables? Are the devs/QAs able to successfully discover and understand every interaction?

Answer 1

I think what you have a the moment is an asset that is somewhere between a design guide and a development framework. What you need depends on how your team's process in transferring design concepts to a built product works, and where the hand-over point is between the designer and the developer. Be careful also not to be too detailed in your wireframes because you want to separate the process/workflow from the actual detailed design, otherwise you'll find yourself having to update a lot more details than you need to.

In a large company with lots of different products, you generally find that a design style guide (which also has to reference the branding guide) is the way to go because the effort of maintaining lots of different assets can be time-consuming if you don't have the resources. But in a start-up scenario where you only have the one product then you should consider creating a development framework that captures both the design and the interactions, which the developers can simply implement directly without having to do any interpretation. This is pretty much what front-end development frameworks like Bootstrap or Materialize offers.

Basically most projects that I have worked on that only deliver a style guide suffers from the problem that you mentioned about developers not getting the whole picture (but mostly because they don't think about UX at all and only the implementation details). But projects where developers leverage a front-end development framework (or go to the trouble of creating one from scratch) suffer from the problem of just plucking things off the shelf without thinking about whether it is suitable for their own specific application or not.

The real solution, to go back to my original point, is to work out exactly what the different responsibilities are (and how much collaboration there is) so you can document and hand-over assets in the best way for the people on the other side of the fence to work on.

Answer 2

Yes, I create fully working prototypes as a deliverable to QA and the Dev team. I have been creating prototypes with html/css/js for a few years and have adopted it into my design process.

What I've found is that static designs and mockups can only get you so far. I mean, we do our best to think everything and during development we notice we had forgotten about form errors, or empty states, or state transitions.

What I do now is start the designs process on paper, go to a digital static design (sketch) and quickly after create a first interactive prototype in html. This helps my design process to not forget about all the little things as different states, errors, etc. When you make building your prototype part of the design process you are not wasting time creating a prototype, you are still designing.

As a deliverable it is great to simply show stakeholders, devs or anyone in your organisation what you are planning. It makes it a lot easier for devs to estimate their efforts and you can simply say, "make this" which reduces documentation immensely. It also allows you to go live with a better first version as you will have fixed all the small little issues you would otherwise only find during the implementation of the product.