Being honest with your designs

Where is the line drawn between being dishonest and trying to bridge the gap between the physical world and the digital world? Where is decoration useful? Where does decoration help the user understand how to interact with the application? When is “flat” too little and “skeuomorphic” too much for the user to figure out how to get his work done?

So, contrary to what the detractors say—there is a place for decoration, and a place for material honesty. These two exist on a continuum, with decoration at one end and material honesty at the other. There’s no precise point at which a design becomes honest or dishonest. The web designer has the messy job of sorting it out.

Material Honesty on the Web by Kevin Goldman

Product Designer Impact

I have been working in enterprise software companies for the last 13 years. I started off working on a team of 4 designers for 300 developers and QA. This meant that I was working on 8 to 10 project teams at a time. If I just went to stand ups it would consume 2.5 hours per day of my time. After 5 years of working like that all we were able to do is create marginal improvements and keep the train from going off the tracks. I consider that experience a failure and so did my manager who decided to announce to the engineering VPs, infront of the lead UI architect and myself who were leading the charge, that the UI team sucked.

Peter Merholz describes this situation in his current post.

Supply and demand of digital product designers

There is a paradoxical risk when designers are in such demand. The demand reflects the value that is seen in design work. But, with such demand, most organizations have too few designers given what they’re trying to deliver. That means those designers are spread too thin, and are focused on execution that keeps the light on. Which means design isn’t being used to its fullest extent, driving not just execution, but product strategy and definition.

Because designers are seen as so valuable, they are not able to deliver their ultimate value. – Peter Merholz

I think that I have learned something that helps address this problem. Currently, my team and I work with the product owners and managers outside of the product teams. There are 28+ product teams. We identify the key problems to work on from the 5 directors of product. Of those priorities we only take on 1 or 2 projects at a time as long as they can be staggered.

We are helping define product strategy and vision. We also work on simplifying the current legacy application so that we can meet the user’s workflows and business needs. We are able to shape the direction of the product at a high level as well as at the basic screen level. The designs are then used to create the stories that guide the developers in their work.

The challenges we encounter working in this fashion shift to organizational and system architecture issues. Since the company never had people doing design in a formalized fashion before, it is a new introduction and change to the organization. The designs go across many teams at one time. Previously, most teams were self contained and now they need to work together. Architecturally, the product was not built to meet the needs of a flexible UI architecture. Every change requires a large amount of re-factoring which always becomes a scheduling consideration.

The pull exists in the organization to go monitor every development team however at this time we remain working with the product owners and managers to explore and create designs that better meet the user’s needs.