A development framework such as Bootstrap and Foundation provides the set of guidelines, tools and components for building interfaces that can be standardized, maintained and extended.

In the same way a design framework should exist to provide the set of guidelines, tools and components for designing interfaces that can be standardized, maintained and extended. However, it seems to be common practice for UX designers to work separately with developers, visual/graphic designers, copywriters, etc to do their work, rather than creating a set of standards that align with existing development frameworks, visual style guides, branding guides, communication frameworks and UI/interaction pattern libraries.

For the purposes of this question, a design framework provides the objectives and intent for the proposed UX design solution (preferably based on business, technical and user requirements/analysis) and includes: a design guideline document that provides the principles and rules to guide the interaction/UI design process, and a design language that is used to describe the user mental model, process workflow, information architecture plus the visual and behavioural characteristics of the interface. Basically, it allows a UX designer to create specifications that is independent of the technology used to implement the solution.

Are these types of standards commonly used within organisations? Is it even important or essential for UX design work? If not then what is the normal process to ensure that a consistent user experience can be created for various products and services.

I think Google Materials Design is the closest example I can think of that represents a design framework, although it is missing some of the user mental model, process workflow and information architecture side of things (understandably so, since each product and service may have different requirements).

  • Can you clarify "work separately with developers"? Do you mean work separately independent of each other?
    – DA01
    Commented Mar 16, 2015 at 20:52

3 Answers 3


Not always

In the early days of waterfall-driven, formal development the answer would have been yes, because slow, formal development cycles and "open-loop", shipped installed-software products meant the cost of reworking UX was very high.

These days, development cycles tend to be iterative and can range from very slow to very fast.

Some examples:

  • For a quick mobile app product, it's often more effective to have developers work from a UX storyboard and stylesheets than to develop formal interaction frameworks.
  • On the other hand, for complex enterprise software with distributed teams and modules a unifying framework can be absolutely crucial.

For most projects an informal cost-benefit discussion with the team is enough to determine what level of formalism to use for UX guidelines. It should incorporate:

  • Size and complexity of application
  • Size and complexity of team
  • Cost of inconsistent UX (nuclear power plant is different from social app)
  • Cost of rework and redesign
  • Development speed vs UX consistency tradeoff

I'm very wary of injecting too much formalism into projects because it can add bureaucracy and really slow things down. A lot of the progress with rapid development in the last decade has come from deconstructing procedural workflow formalism (aka bureaucracy) and instead embedding it into technology to drive consistency (css, github, jquery etc).

Design guidelines tend to be procedural rather than tech embedded so I try to adopt an as-needed rather than policy-driven approach.

  • 1
    To support you argument that formalism increases with complexity, BBC global experience language is a good example.
    – Okavango
    Commented Mar 16, 2015 at 18:24
  • @okavango lol I never had the pleasure but if you have 60 hours of free time check out this 537 page monstrosity: microsoft.com/en-us/download/details.aspx?id=4249
    – tohster
    Commented Mar 16, 2015 at 18:38
  • @tohster Design frameworks don't have to be complicated beasts... good examples include the Atlassian Design Guidelines (design.atlassian.com/latest) and Google Materials Design (google.com/design). Actually, those are probably the standout examples I can think of.
    – Michael Lai
    Commented Mar 16, 2015 at 21:43
  • @tohster Also, I believe that design frameworks is not just about a formalisation of the implementation details, but an explanation of the rationale and thinking behind the design so that development frameworks can be applied in a consistent and logical manner. Thoughts?
    – Michael Lai
    Commented Mar 16, 2015 at 21:47
  • @MichaelLai it might be just semantics. I like Material Design a lot and have been using it since it came out. So you could say that I've been using a design framework. But I don't always ask my dev teams to go read Google's MD specs, because it's just not necessary for small projects. So although I'm using a framework, I'm not sure if it qualifies as real framework use if it's not used cross functionally as you point out.
    – tohster
    Commented Mar 16, 2015 at 23:58

Yes, for one very simple reason.

It helps your team formalise a point of view. Even if the documentation isn't used by everyone, the process of creating it makes you and your team build an opinion and point of view which helps you in anything longer than a few months ahead.

Remember that the frameworks you use to execute design like bootstrap were not your original creations - they're someone else's opinion on a design system. Please designers - build your own points of view :)

  • That last point you have made is so important! I don't really believe in sticking to the guidelines for the sake of doing so... this is people are always confused and arguing about Windows and Apple design guidelines. In the end it might not even be applicable to your own products and users.
    – Michael Lai
    Commented Mar 16, 2015 at 21:45

Yes they are, at least for me. Just based on environment (project, company, specific product) I pick the subset of the frameworks/tools. I am the first one to apply them and introduce them as the whys behind the design to the rest of the team. The rest is teaching and tweaking based on collected feedback from the whole ecosystem. Starting with a few heuristics to keep an eye on is the most common case and the "framework" is grown as needed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.