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)

Sorry but can you elaborate on what you mean by a mockup toolkit,is it just a collection of mockups and style guides ?
–
Mervin JohnsinghMar 7 '12 at 6:12

To begin with, it will just be a collection of UI elements (buttons, tables, controls, etc.) and perhaps some empty browser window templates with gridlines to show where our fixed elements like navigation will go.
–
dennisleesMar 7 '12 at 6:17

Bootstrap is implemented in live CSS and HTML; why would you take that a step back to bitmap images? Seems counterproductive to me.
–
Rahul♦Mar 7 '12 at 9:48

1

Because I'm dealing with 25 people in 3 countries, with different levels of code-savvy ranging from expert to clueless. Suggesting that we all start working in html/css is not an option.
–
dennisleesMar 7 '12 at 15:48

3 Answers
3

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.

Thanks for the input, but I'm not exactly sure why it's being upvoted. "Just make them write the html/css themselves" is not a reasonable suggestion in this case; some product owners have are not code-savvy in the slightest. Also, the whole point of using the Bootstrap elements is to be restrictive. These people are not UI designers, and they're also prone to overcomplicate processes. So by limiting the options, I keep things simple and looking good. I understand that the process needs to change, but that's a multi-year project. This is a damage-limitation step I can put in place within weeks.
–
dennisleesMar 7 '12 at 15:45

That's why I recommended the engineers write the HTML, not the product owners. Further your responsibility as the UX person is to help them not overcomplicate things by communicating better with them, not by giving them Twitter Bootstrap. If you've already decided what the solution is (throw Bootstrap bitmaps at them), then why did you come here and ask a question about it?
–
Rahul♦Mar 7 '12 at 15:58

1

The question was "Best way to deliver...?" Not "What are the flaws in my philosophy?". You're answer was great, just not what I was asking for; maybe a little bit idealistic, and certainly not realistic given the real-world limitations I face. I have a plan and I'm looking for way to deliver it. Hence wording of the question. Thanks.
–
dennisleesMar 7 '12 at 18:44

Have you considered that I am in fact answering your question, just not the way you wanted me to? I'm sorry that it's not what you want to hear, but if you were my colleague this is what I would tell you. I wouldn't just tell you what you want to hear because that's more convenient. I don't intend to point out flaws, I'm just pointing out that the solution to your problem isn't a "mockup toolkit", it's better communication with your team. It's only unrealistic if you decide that you don't want to put in the effort of solving the problem.
–
Rahul♦Mar 7 '12 at 21:09

It seems as though I'm not accepting your sage advice and you are insulting my work ethic, or intelligence, to compensate. I do want to change this system, but even if I didn't, it would't make your suggestions any more realistic. Those two concepts are unrelated. If you were my colleague we wouldn't be having this conversation, because you'd have some understanding of the existing culture and its limitations. So please, accept my thanks for your input so far, hear me when I say that it's sound but not appropriate, and let's let this go.
–
dennisleesMar 7 '12 at 23:50

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.

If you're looking for a toolkit to build prototypes or mockups based on Twitter Bootstrap, I'd recommend using the Keynotopia UI components for Powerpoint. You can download some for free here: http://keynotopia.com/bootstrap/