Warning: file_get_contents(http://www.linkedin.com/countserv/count/share?url=http://freshpractices.com/how-a-small-team-can-make-a-big-impact/&format=json): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/customer/www/freshpractices.com/public_html/wp-content/plugins/tk-social-share/tk-social-counter.php on line 145

Looking for some documents for another post, I ran across this list of accomplishments for a particular quarter of 2001 when I was UE Manager at PentaSafe, a security software company later acquired by NetIQ.

Reading through this, I see things we did that I don’t even recall well, like a UE and You! newsletter distributed to R&D – I’d love to see that thing! I began thinking about how our tiny little team – no more than 4-6 people at different times – could manage to not only re-brand and release 35 products on traditional software schedules of a release every 2-6 months, but also create new product prototypes, design new integrated products and features (part of a master plan to dominate the security market we were working toward) and work with Sales and Marketing departments on various initiatives in addition to conducting formal usability testing.

There was a method to this madness.

Rebranding a multi-product line is best done in phases in my opinion, and that will take a spirit of compromise, strategy, and willingness to deal with temporary imperfections as you work toward the ideal user experience. (For example, there was a time when some of the packaging did not match the product.) I have seen some large companies dawdle to the point of looking out-dated next to competitors, because they are afraid to make changes to legacy products or their branding to update everything, it’s so overwhelming. We’ve all seen companies that redo a logo, rather pointlessly (JCP and The Gap come to mind), when product changes or foundational changes to customer service and focus on the mission is needed more.

Here are some tactics I used to enable our tiny team to create a big, organization-wide impact at PentaSafe:

 Work with (or for) an executive Champion.

The person who had the idea to create a UE department and asked me what it would take to bring user experience into the software development process company-wide was Bill Vance, VP of R&D, who spent 30 years at IBM prior to coming on board this 5 year old startup to get R&D working as one machine, rather than 9 individual teams making disparate products. He taught me so many lessons and was the best mentor and champion of change I’ve ever had. I have used those lessons in every project or job I’ve held since then. Without his backing at the C-level, some of these changes would not have happened. You need someone in high-level management who believes in listening to your suggestions and approach. Without champions that can push things through, you may find yourself beating your head against closed doors and walls. He once told me he hired me because I thought differently than he did, also. That’s an open-minded champion!

ps_vimbrand Design from the big picture, long-term perspective from the beginning.

We began with the organization of products in 4 marketing buckets and I worked with Marcom and Product Marketing on color-coding and copy so that our product colors, names/labels and design were always aligned with the marketing messages. We then had to train the sales department and engineers to understand new or renamed terms, to keep everything aligned, and documented it all for reference.

This was mission critical for crafting a smooth user experience across the VigilEnt product line. This is how the products broke down in terms of parent products, add-ons and color categorization. In the image to the right, you can see the marketing wheel and how a single product in the red category looked to users.

Loader Loading...
EAD Logo Taking too long?

Reload Reload document
| Open Open in new tab


 Break the big picture design into detailed tasks for each product.

Once you understand the big picture design and user experience goals, you can break things down into granular tasks, ie. “Replace all old logos with the new logo in this release.” You may not be able to fully brand the product like you want to in a single release, or get everything fixed that is driving you crazy at once. That’s okay – incremental change is better than no change.

 Plan product changes in coordinated phases.

Using the logo example above, you need to know what windows of opportunity you have to slip in cosmetic changes, and see how closely you can align changes into these different products. With 35 products, something was always being released monthly, though not always as a major or minor release. In the security industry you have vulnerability releases to patch something from Microsoft or BEA WebLogic for example, and these releases became a vehicle for adjusting cosmetic issues that were not too invasive. So I tried to do front-end things like logos and headers at once, across all the products. We got the packaging and installation graphics switched with the product interior graphics if we could. We cleaned up old icons and got rid of old graphic artifacts every release until complete, replacing them with our new, consistently labeled icons and locations (like putting the Trash icon in the same place, with the same functions available.) Then the next round of releases we cleaned up more issues or added another level of integration. This rebranding spreadsheet is what I used to help our team keep track of what remained to be done.

You will need to employ a lot of patience, negotiating skills and compromise with developers, marketing folks and management to get this done. I asked to change things I often did not get to do immediately, and I was okay with that, even though the uxp was not ideal. It gradually got better, from a shallow cosmetic level down to an actual integrated level on the backend (products talking to each other.)

 Make smart choices, not just cool choices.

Since these products were delivered for installation on CD’s (mostly – updates were done digitally) we had the scenario of the product that was burned to the CD possibly not containing a patch or something that had changed between completing the product release and sending. So we worked with Distribution on the packaging and items inside the package to do things in a way that minimized waste and offered the best uxp.

We had empty CD’s printed in bulk, and put products on them to order. The errata documentation (it was so cool – I will try to find my examples) was color-coded and printed blank so that it could be run on the printer to be most accurate. Our physical Quick Start manual covers were printed in large quantity in color, and then the interior was sent to the printer and printed in smaller quantities and stapled together and sent to us just prior to release. So sometimes on the errata we had to make a correction until the next batch of that manual was printed. Our colored packaging was all generic, no version numbers on it, with that detail added to what was printed in-house or on the first page of manuals so we did not waste our branded, more expensive packaging for manuals and CD covers.

Making choices like this that save money yet brand the product line sufficiently will endear you to management, and you can still offer a great user experience.

 Simplify messaging and clean up the words.

One of the biggest problems you can get into with a multi-product line is that the products are usually developed by different teams, and the words used to describe common tasks, features and functionality can get inconsistent fast. You can’t rely on QA to catch all of these tiny inconsistencies – in my opinion, the marketing and UE department folks need to take this on and help find issues and get them into the bug-tracking system so they are fixed. They are more familiar with the big picture vision and QA is meant for finding and getting more technical issues fixed. The words used can make a huge difference in the overall product quality, and if you influence sales and marketing to all use the same language the products do, you will be well on your way to improving the user experience for people using more than one of your products.

 Write tasks in user-friendly language.

In this first image, you will see the marketing wheel and four products, all of which were integrated with another product called VSOC (VigilEnt Security Operations Console), if your enterprise setup had a mix of hardware to manage.


This is VSOC, the umbrella console, where you can read the tasks on the left a little easier.


With this design, I wanted to give users a “soft landing” which is why the opening pane has a giant image of the most common tasks the average user will need to do.

The products all used the traditional tree model, and these same tasks are accessible via the tree, but I found the learning curve of figuring out on your own what to do, or having to go by the Quick Start manual, too steep and cumbersome. IT people who used these products were a mix audience of advanced professionals and junior team members, new to IT and/or security. So in layman’s terms, we wrote the tasks out and users could use the tree (a lot of advanced Windows users preferred it) or they could shut that pane totally and use the colored pane to navigate around and do their work. I used to tell my doc writers I wanted the clearest, most fabulous documentation they could write, and I didn’t want anyone to read it. I’m sure they loved that. 🙂

This is one of the products that had VSOC installed. You can see that task panes could be opened or closed to get unneeded tasks out of the line of sight, reducing clutter. Also notice the tiny shield icons upper right – that is how users switched to another product.


Design products to sell, not just to be used.

As a UI designer or user experience pro, you must consider the very FIRST user of your products: the salesperson. The impression a product makes during a webinar, presentation or in-person demo is critical to the ultimate sale. In the case of the above product, imagine how much simpler the product looked with the tree shut (which was the default setting.) Whether the salesperson was in a selling situation or a sales engineer was on-site helping install the products, we tried to ensure that the first impression was a good one, and gave the perception that our products were easy-to-use.

I used the word “perception” on purpose. In the case of all these security products, they were being gradually integrated into the console, but this took time. So users actual saw what I call a layer of “visual integration”, meaning the cosmetics and most of the labels and some tasks were aligned, but the product was not fully integrated on the back-end or consistent on all the front ends. This visual integration helped us sell products prior to them being more usable, or having been fully redesigned.

 Don’t sweat what you can’t change.

While all of my Windows-based products and the web interface products could look like each other, when it came to the Unix team we had issues with both pushback and technical limitations or things that just worked differently physically, like the way things looked on the screen from that OS. So the design was similar, but not exact. This is one case of just letting go of full control to get product out the door as consistently as I could given all the circumstances. (I am assuming that intro note about impressing your boss with 500 page daily reports was an internal joke!)


One time we were in a manager’s meeting, and product marketing announced they had a giant sale from a potential customer if we would design something in that they wanted. As in, they had already promised we would, without talking to R&D first. With already set product schedules, milestones and features bursting at the seams to try to get done, this was not welcome news. All of the R&D managers just looked at each other with fairly disgusted looks on their faces. But… we buckled down and made the attempt to cram in this new stuff and get it done in time to be competitive with another company in the market we were trying to beat to the punch.

Just remind people when things are getting off track or inconsistent according to the big picture vision, but don’t feel like it all has to be perfect overnight or freak out if your best-made plans get altered by someone else, and you’ll sleep better.

 Learn the art of influence without ownership.

One of the most valuable lessons I learned from my boss and mentor Bill, was that he expected me to create change within the company without necessarily having any ownership of additional things or being held accountable for it. I learned this because I kept wanting to take over things. Like distribution, packaging and Beta programs. 🙂

Since I had to, I wound up finding ways to work with the managers and team members responsible for those areas, to influence making the experience better. In the case of Beta’s, I worked with the product marketing team to structure them so the UE team was included in the process and could gather meaningful data during that time, since customers were already engaging with us on the product design, so I did wind up with partial accountability but his lesson is one I will never forget when working around things I feel need to change, but that aren’t in my domain to do so quickly.

 Don’t over-do mandatory processes.

Creating an end-to-end user experience was our goal, and that meant from the moment of first mention or seeing an ad for the product, to the product being taken out of production and no longer sold. I worked with a small team of people on a 9-phase Software Lifecycle that we then had to educate all the teams and departments to use… and force some compliance with as this was a totally new ordeal for them.

We put in some UE milestones, but did not put in everything we might possibly do during a project so that we could stay adaptable and flexible, while still ensuring that the user experience was deliberately addressed during development. By doing this, we had less pushback and more cooperation from team members, who agreed that more UE activities might be part of the product plan, depending on release type and time. I found four official UE Process documents in my archives but am not sure that’s all we made mandatory checkpoints. I will hunt for the Lifecycle and write about it someday as it was pretty well planned, in my humble opinion.

That’s my best advice for a small team that needs to scale big. Hopefully some of these tips will help you, if you work on a large or integrated product line. Achieving your vision and delighting users is worth the pains!

Leave a Reply

Your email address will not be published. Required fields are marked *