–Engage

“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It's not about money. It's about the people you have, how you're led, and how much you get it.” - Steve Jobs

What are and how I have come to use design principles in my practice

I was first introduced to design principles in 2009 from @LukeW (Luke Wroblewski) in his great Interaction09 talk in Vancouver (see it here):

Luke Wroblewski – Parti and the Design Sandwich from Interaction Design Association on Vimeo.

His follow up article on principles was also really clarifying about their value and about what is and what isn’t a principle.

What his article & talk don’t cover is how to create the principles and how to use them as part of your design studio practice. This is an area I have been quite fixated on of late, in my new role as a design principal at Rackspace (@rackspace), because I see the use of principles tied directly to managing design(er) quality (my mandate here).

While Luke does a great job in his talk and article of describing what makes a good design principle I have had some thoughts that extend some of his thinking. When I speak about “what is a design a principle” I think about a way of describing what you want to achieve (an outcome) in the artifacts that you design if you were done with the work. If someone was to describe your design(s) how would they do that using a creative and critical language. The trick is that you aren’t describing what exists, but rather describing what you want to bring into existence. You then know you are successful with your designs (on one plain) because when you look at your completed design, using your principles would design a substantial amount of it.

What isn’t a design principle is a phrase that suggests how you would achieve it. One of the bigger offenders I see to this regard is “We will observe users,” or a similar call to action about research. A design principle also can’t be too broad as to be anything. E.g. I hate the principle of “intuitive”. I call these the table stakes of any design. So if you would put it in a book for any designer on the planet, it probably isn’t a useful design principle for you because it doesn’t help you make decisions for your unique context. Design values like “intuitive” or “responsive” are helpful in that they can be filters through which to create deeper principles that address those, or embody those values.

The best design principles are specific enough to limit the number of possible variations and broad enough to allow for significant interpretation, especially over time, or as more data comes into the production/design system. Principles can and do evolve through a product lifecyle (single releases), or through a product’s life (multiple releases) as different types of data come into the system, especially customer feedback (passive and active).

One of my favorite collection of design principles are those created by Microsoft for their Metro user interface (and beyond). One criticism I would make of them is that they are written as pithy statements. Otherwise, though, they are well presented and well executed: (add picture)MS Metro Design Principle

  • pride in craftsmanship
    • get on the grid
    • it all stacks up
    • who are you?
  • more with less
    • content over chrome
    • let your content breathe
  • fast and fluid
    • be alive
    • motion
  • authentically digital
    • info is in
  • win as one
    • think platform

Like I said I think these are great, but they are not without critical review themselves. The last one for example “think platform” is a great platitude, but not really a design principle. It’s an example of a table stake I mentioned above. Maybe at the time when Metro was made it wasn’t quite as entrenched as it is now. A great example of how your principles evolve with or without you.

But why these principles? Obviously, they were reacting to the market space and definitely allowing themselves to be inspired by great design generally, but they are also created by watching people. Watching people use competitors; iterating prototypes; and from inspiration of other design sources all contributed to these principles. They are all data points of value.

But is there a way to be more deliberate in the creation of design principles? Can they be more data driven and more data responsive? This is an area I hope to explore more, but I want to create design principles based on design research that creates personas with scenarios combined with psych aesthetics profiles. I hope to have more on this in the coming year.

We use principles as our guides. They don’t tell us exactly which way to turn, but they give enough information to know we have really spun this design in the wrong direction. They are used at any moment where evaluation is being done in the design and development process but the only real place they have to be is during a design criticism.

So how does this play out in the real world?

Creating principles comes from insights made through the combination of research and design exploration. Research is synthesized into scenarios using personas as actors. The scenarios like any script already can begin to be described as a set of principles. Following the scenarios, design artifacts are made that explore these proto-principles that can be evaluated in their own right against both the scenarios themselves, technology feasibility, and business goals. It is important that a multiplicity of interpretations can be made at this stage. Otherwise, this isn’t exploration and just iterative guessing.

It is important that principles speak directly to describing ideal design decisions and not the process of making those decisions. Too often things like “based on research [or data]” or “test often” are used as design principles. But these are team values and not design principles because they only say how to do design and not how to guide a decision. The other type of “wrong principle” are ones that are too vague, or what I call “table stakes” (duh requirements). These usually like like “be intuitive” or “must have strong feedback”. A great way to know your principle falls in this last category is if it is either a) Jakob Nielsen’s 10 Heuristics; or b) Tog’s First Principles of Interaction Design. These are not project specific and should be the same principles and heuristics that everyone on the planet should flexibly follow. They are of course, always in your critique tool belt as all of your team should be steeped in them.

Looking back at the principles from MS. They start out with a principle category that I would consider a table stake of any organization committed to quality, craftsmanship. Then they take that and dig deeper into how they interpret it. Grid, Generous white space, and Appropriate Type. But let’s remember that these principles are less about “Metro” (the platform) and more a guide to 3rd party developers who will be designing applications for Windows platforms.

Example principles that I do like, that I feel would be specific enough would be like these:

  • Information display should always lead to clear choices of action.
  • Choices of action should be presented using data as a means to prioritize for the user
  • If the system can do it for the user, it should
  • Progressively present information and options, so as to limit clutter and guide users based on their appropriate level of experience.
  • The look should be refined, clean, forward leading (edge or beyond), structured

You know they are good because not every context would want to have them. Additionally, there is room for lots of variability within the constraints they represent. On the one hand, they may feel like requirements, but the feel we want is more of a design brief about all UX components: IxD, graphic design, information architecture, etc.

It is also important not just to create the principles, but that the creation of the principles is done with a cross-functional team. The principles should impact everyone from designer to marketer to developer to quality engineer to sales person. They will help align the team the same way a set of corporate values or a mission does at a higher level.

Now enter the crit:

Each person who presents in a crit does so with the principles in their mind, In fact, they should present their work with a clearly stated connection not just to the principles, but how their interpretations and contrasting viewpoints are addressed in their designs. Their goals explicitly stated against the principles will be the backdrop of how critique is given. Because everything presented is based on goals and principles the criticism then is focused on that, criticism gets focused on those issues as well.

Criticisms are not formulated as directions or opinions, but rather they are crafted as questions about how the designer met their stated goals, or whether their goals map against the intent of the principles. Then the group responds, not with suggestions, but with complimentary questions. Only the designer of the criticism can make suggestions of new designs using a directive tone. In this way the designer remains the owner of the design and the last word.

Yes, sometimes directions do need to be given, especially by managers to younger designers, but these should be done post criticism in private one-on-one meetings that are safer for the designer and where a manager can give more coaching than they would have otherwise been able to.

Be Sociable, Share!

Search

The archives run deep. Feel free to search older content using topic keywords.