4

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?

2 Answers 2

2

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.

2
  • Currently we provide wireframes per project and also provide a global style guide. Dev and QA consume those documents without issues. We walk through these docs with them and we are always available for questions. My concern is the additional deliverable of providing fully functional prototypes. As of right now, our prototypes are being built with Invision, so they are very limited and their purpose is for user testing key tasks only. Building out a fleshed out prototype would probably require Axure and take up valuable time when we could be designing instead.
    – G Dub
    Jun 10, 2016 at 17:09
  • @GDub If you have wireframes and they capture the functional requirements and can be used to communicate with the business stakeholders and developers then you are in a good place. The global style guide is mainly for the visual design aspects so I guess the gap is an interaction design guide (a design framework would cover both by default, e.g. Bootstrap). If you run a pretty good Agile software development process then why not go straight into prototypes rather than doing basic prototypes with Axure? You are right in saying that time could be better spent designing or testing.
    – Michael Lai
    Jun 10, 2016 at 22:35
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.