Are design frameworks, design guidelines and design languages essential for UX design work? If not, what is used instead?

Question

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).

Answer 1

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.

Answer 2

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 :)

Answer 3

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.