Q:

Best way to deliver "mockup tool kit" to engineering team?

I've recently assumed the responsibility of shifting the design culture at a very technology/feature-focused company. (Our "product" is a web portal that customers use to manage the lifecycle of digital certificates) 
Currently, our "tech team" (software engineers & product owners) create mockups of new task flows in Excel by taking screenshots of the existing UI and drawing shapes/making notes on top. I feel that this practice informs the end product and would like to move away from it.
I'm planning to embrace the Twitter Bootstrap UI elements in an upcoming overhaul and I'd like to restrict the mockup process to just those elements (i.e. so that the tech team can only create new task flows using this group of UI features)
My vague plan is to deliver the assets as bitmap images (though I also have them as vectors) along with some general layout grid templates, and recommend one piece of software that they all should work in (for consistency). 
So my questions are: 

How do I best deliver this mockup toolkit?
Am I just being anti-Excel, and should I just let them stick to what they know? 
Would Powerpoint be a better tool in this case (as an example of software that can be used for layout and that they already have and use?
Is it worth putting in the effort, and trying to get them to change their workflow and use a tool that was more specific to the task, and what might that be?

(I should point out that they are all non-native English speakers, so that's a consideration)

A:

I've come across Excel prototypes in the past so I understand why it can be neccessary to provide a mockup toolkit.
Rahul is right you should think about what the purpose of the prototypes/mockups is and then decide what tooling you use.
The idea to provide a set of elements can improve the mockups at first, since right now the engineering team is going all wild with excel. Though in the longer perspective I would suggest to decide for a certain prototyping process and the according tool.
Generally mockups can be made in any tool. Its important, that the people feed comfortable with this tool. Otherwise it limits their creativity for the task at hand. Excel is really widely used, I guess thats why people start prototyping with it. Though there are really easy tools for simple mockups available. These tools don't export shiny designs rather than a wireframe look. This is great for defining functions and interactions, decide which buttons fields, list you need. Once you agreed on that, you can start with the visual design.

A:

Mockups are not deliverables, they are documentation meant to facilitate communication between team members. So I would recommend approaching this as a documentation problem rather than a mockups problem.
Product owners will likely want to continue describing features and flows in tools that they are familiar with. Since you're just using these documents to facilitate communication, it's okay if they use Excel. Whatever works for them that helps them communicate their intents and expectations.
Engineers, however, are perfectly capable of using HTML and CSS. So I would recommend helping them see mockups as part of a design process and get them to start implementing them in HTML as soon as possible. This also improves communication because then you have a document (a HTML prototype) that you can discuss with stakeholders. Especially in the case of task flows this can be very important. You should get into this phase quickly rather than languishing in the realm of Excel spreadsheets and pictures of things.
Finally, don't restrict the team to using only UI elements in Bootstrap. Bootstrap is a starting point, not a destination. It's meant to help you bootstrap your environment so that you don't have to worry about visually styling something. It's great for engineering teams who don't have access to a visual designer and don't want something unattractive. It's not meant to be a set of standardised UI elements that dictate the restrictions of a product.
Instead, your responsibility is to determine a library of relevant UI controls and create documentation that outlines how you recommend using them. But the team should be free to step outside those guidelines, or else you risk forcing them to misuse certain controls to accommodate product owner wishes that don't fit.
If you're looking for specific tools, there are a few that I can recommend, but I don't think you should be looking for tools initially; you should be looking to improve the design and communication process in your team. Which tools you use is secondary.

