Drink Your Kool-Aid

Silos Are for Grain: Part 5 of 5

We’ve almost made it. Throughout this series, we’ve covered how (within the enterprise product development process), your design team can effectively build compelling products while optimizing your relationships with your cross-functional teammates — hence the name: silos are for grain.

Always remember: your design can’t do anything without engineers to build it and product managers to drive that development.

The hard part is over — we’ve covered Research, Iterations, Prototyping, and Selling your idea.

But now that that your walkthrough and high-fidelity mocks have been approved and passed on to the development team, there’s still one last very important step left. It might not be the most enjoyable step, but in order for any digital product to ultimately be successful it is absolutely critical: Dev Support.

You’re No Swami

After all of the in-depth work that we’ve done as designers, we like to believe that every use case has been accounted for and every edge case has an associated mock.

Well, it’s not.

As I mentioned in previous articles, the engineering team that’s actually building your design is going to have to make hundreds if not thousands of design decisions as they take your pretty pictures to an actual functioning product. This is when the communication lines need to be more open than ever.

The building isn’t the only stage that needs your involvement. Depending on how risk averse your organization is, you might have a beta or even an alpha program to limit the release before putting it into the hands of the general public. If there are calls or meetings associated with those alphas or betas, make sure that you are in those rooms. Some of the best feedback will come once the users are interacting with the new designs on a daily basis and once it’s been integrated into their workflow. All the work we did previously was to get as close as possible to the final solution — but we’re still not there.

You’re Most Empathetic to Yourself

Up until this point, your entire design process has been focused on a singular goal: Understanding the users and solving their problems. But now, with a few exceptions, there is a lot of value in taking our understanding to the next level.

We must become the user.

This was pretty easy for us when I was working on Adobe Analytics. There was a pretty direct relationship between the work we were doing as designers and the insights that we could get out of the analytics tool. So we started using the tool that we were designing regularly as a design team, and some of the best insights and design iterations came from us feeling the pain of certain interactions that had seemed so logical at the time.

Sometimes it’s a bit more complicated, but I think with just about any digital product you should be able to adopt it and use it on a semi-frequent basis in your day-to-day life. Do you work for Salesforce? Set up a CRM with all of your friends and use it to say happy birthday. Do you work for Entrata? “Charge” your significant other or roommates their monthly rent and/or utilities using that system. You get the point.

By becoming that user and putting yourself in their shoes, you will find insights and improvements that you never would have discovered otherwise.

Finally, one other fringe benefit that we saw that is worth mentioning is the impact that your usage will have on the trust that the product owners and development teams have in you. It shows a dedication to product excellence in addition to a willingness to “get your hands dirty.” Of all the suggestions that have been made in this five part series, I don’t think there is a single thing that had a bigger impact on our team for getting our cross-functional teams out of silos than this last step: drinking our own Kool-Aid.

Closing Thoughts

Well there you have it folks. Bear in mind that this five part series was not by any means intended to cover the full enterprise digital product design process. More than anything it was intended to highlight some key findings that I’ve had while working on establishing better cross-functional relationships.

So get out there and deputize your engineers and your product managers as designers. Teach the basic design process to them so that they can be equipped to make design-centric decisions in the hundreds of micro-decisions they make every day. Nothing good can from us sitting in our design ivory tower.

We’re all on the same team, after all.