4 replaced http://ux.stackexchange.com/ with https://ux.stackexchange.com/
source | link

Example Style Guides

For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, Gnome) for the organization, issues, and topics you may want to have. Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes have compliments for forms. There’s also guidelines for web sites, (e.g., usability.gov), but these will generally be less useful for applications.

What to Include

For the basic approach, see answers to How did you create design guidelines for your organization?How did you create design guidelines for your organization? To answer your specific question, I make a distinction between “elements,” or pieces of a UI (records, fields, layout, forms, command, and feedback), and “functions” (what some might call “patterns”), which assemble multiple elements into a standard UI for a common step in the user’s tasks (e.g., login, query, reports, undo, sort, zoom, help). I cover both in a style guide.

The idea of a style guide is to avoid you having to design everything yourself, so if a custom function only exists in one form, don’t include it in the style guide. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite.

The Deliverables

Ideally, the ultimate form of the style guide should be what works best for your users –not the tool/suite users, but the developers and designers that will use the styled guide to make the tool. A style guide should make their job easier, not harder. If it’s too hard for your users to find the right guidelines for a particular case, or learn and understand them, or implement them, they’re not going to. You can apply your UX skills to making the guideline deliverables by interviewing and observing your designers and developers to find out what will work for them (in your case, you may be limited to phone interviews with your developers; better than nothing).

This implies the product may employ multiple media. Chances are the “main” product will be some sort of hyperlinked document, which has obvious advantages for reference material. However, there may also be a summary quick reference guide or checklists, printable posters to promote the guidelines and highlight key features, a library of style-guide-compatible templates / patterns / CSSs, and seminars and workshops (possibly conducted remotely) for you to personally introduce the guidelines and show their advantages for the designers and developers. Frankly, creating the guidelines is only the start. Most of the work is promoting and enforcing the guidelines. Try to get the time, budget, and organizational support for that.

Example Style Guides

For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, Gnome) for the organization, issues, and topics you may want to have. Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes have compliments for forms. There’s also guidelines for web sites, (e.g., usability.gov), but these will generally be less useful for applications.

What to Include

For the basic approach, see answers to How did you create design guidelines for your organization? To answer your specific question, I make a distinction between “elements,” or pieces of a UI (records, fields, layout, forms, command, and feedback), and “functions” (what some might call “patterns”), which assemble multiple elements into a standard UI for a common step in the user’s tasks (e.g., login, query, reports, undo, sort, zoom, help). I cover both in a style guide.

The idea of a style guide is to avoid you having to design everything yourself, so if a custom function only exists in one form, don’t include it in the style guide. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite.

The Deliverables

Ideally, the ultimate form of the style guide should be what works best for your users –not the tool/suite users, but the developers and designers that will use the styled guide to make the tool. A style guide should make their job easier, not harder. If it’s too hard for your users to find the right guidelines for a particular case, or learn and understand them, or implement them, they’re not going to. You can apply your UX skills to making the guideline deliverables by interviewing and observing your designers and developers to find out what will work for them (in your case, you may be limited to phone interviews with your developers; better than nothing).

This implies the product may employ multiple media. Chances are the “main” product will be some sort of hyperlinked document, which has obvious advantages for reference material. However, there may also be a summary quick reference guide or checklists, printable posters to promote the guidelines and highlight key features, a library of style-guide-compatible templates / patterns / CSSs, and seminars and workshops (possibly conducted remotely) for you to personally introduce the guidelines and show their advantages for the designers and developers. Frankly, creating the guidelines is only the start. Most of the work is promoting and enforcing the guidelines. Try to get the time, budget, and organizational support for that.

Example Style Guides

For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, Gnome) for the organization, issues, and topics you may want to have. Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes have compliments for forms. There’s also guidelines for web sites, (e.g., usability.gov), but these will generally be less useful for applications.

What to Include

For the basic approach, see answers to How did you create design guidelines for your organization? To answer your specific question, I make a distinction between “elements,” or pieces of a UI (records, fields, layout, forms, command, and feedback), and “functions” (what some might call “patterns”), which assemble multiple elements into a standard UI for a common step in the user’s tasks (e.g., login, query, reports, undo, sort, zoom, help). I cover both in a style guide.

The idea of a style guide is to avoid you having to design everything yourself, so if a custom function only exists in one form, don’t include it in the style guide. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite.

The Deliverables

Ideally, the ultimate form of the style guide should be what works best for your users –not the tool/suite users, but the developers and designers that will use the styled guide to make the tool. A style guide should make their job easier, not harder. If it’s too hard for your users to find the right guidelines for a particular case, or learn and understand them, or implement them, they’re not going to. You can apply your UX skills to making the guideline deliverables by interviewing and observing your designers and developers to find out what will work for them (in your case, you may be limited to phone interviews with your developers; better than nothing).

This implies the product may employ multiple media. Chances are the “main” product will be some sort of hyperlinked document, which has obvious advantages for reference material. However, there may also be a summary quick reference guide or checklists, printable posters to promote the guidelines and highlight key features, a library of style-guide-compatible templates / patterns / CSSs, and seminars and workshops (possibly conducted remotely) for you to personally introduce the guidelines and show their advantages for the designers and developers. Frankly, creating the guidelines is only the start. Most of the work is promoting and enforcing the guidelines. Try to get the time, budget, and organizational support for that.

3 broken link for gnome style guide
source | link

Example Style Guides

For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, GnomeGnome) for the organization, issues, and topics you may want to have. Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes have compliments for forms. There’s also guidelines for web sites, (e.g., usability.gov), but these will generally be less useful for applications.

What to Include

For the basic approach, see answers to How did you create design guidelines for your organization? To answer your specific question, I make a distinction between “elements,” or pieces of a UI (records, fields, layout, forms, command, and feedback), and “functions” (what some might call “patterns”), which assemble multiple elements into a standard UI for a common step in the user’s tasks (e.g., login, query, reports, undo, sort, zoom, help). I cover both in a style guide.

The idea of a style guide is to avoid you having to design everything yourself, so if a custom function only exists in one form, don’t include it in the style guide. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite.

The Deliverables

Ideally, the ultimate form of the style guide should be what works best for your users –not the tool/suite users, but the developers and designers that will use the styled guide to make the tool. A style guide should make their job easier, not harder. If it’s too hard for your users to find the right guidelines for a particular case, or learn and understand them, or implement them, they’re not going to. You can apply your UX skills to making the guideline deliverables by interviewing and observing your designers and developers to find out what will work for them (in your case, you may be limited to phone interviews with your developers; better than nothing).

This implies the product may employ multiple media. Chances are the “main” product will be some sort of hyperlinked document, which has obvious advantages for reference material. However, there may also be a summary quick reference guide or checklists, printable posters to promote the guidelines and highlight key features, a library of style-guide-compatible templates / patterns / CSSs, and seminars and workshops (possibly conducted remotely) for you to personally introduce the guidelines and show their advantages for the designers and developers. Frankly, creating the guidelines is only the start. Most of the work is promoting and enforcing the guidelines. Try to get the time, budget, and organizational support for that.

Example Style Guides

For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, Gnome) for the organization, issues, and topics you may want to have. Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes have compliments for forms. There’s also guidelines for web sites, (e.g., usability.gov), but these will generally be less useful for applications.

What to Include

For the basic approach, see answers to How did you create design guidelines for your organization? To answer your specific question, I make a distinction between “elements,” or pieces of a UI (records, fields, layout, forms, command, and feedback), and “functions” (what some might call “patterns”), which assemble multiple elements into a standard UI for a common step in the user’s tasks (e.g., login, query, reports, undo, sort, zoom, help). I cover both in a style guide.

The idea of a style guide is to avoid you having to design everything yourself, so if a custom function only exists in one form, don’t include it in the style guide. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite.

The Deliverables

Ideally, the ultimate form of the style guide should be what works best for your users –not the tool/suite users, but the developers and designers that will use the styled guide to make the tool. A style guide should make their job easier, not harder. If it’s too hard for your users to find the right guidelines for a particular case, or learn and understand them, or implement them, they’re not going to. You can apply your UX skills to making the guideline deliverables by interviewing and observing your designers and developers to find out what will work for them (in your case, you may be limited to phone interviews with your developers; better than nothing).

This implies the product may employ multiple media. Chances are the “main” product will be some sort of hyperlinked document, which has obvious advantages for reference material. However, there may also be a summary quick reference guide or checklists, printable posters to promote the guidelines and highlight key features, a library of style-guide-compatible templates / patterns / CSSs, and seminars and workshops (possibly conducted remotely) for you to personally introduce the guidelines and show their advantages for the designers and developers. Frankly, creating the guidelines is only the start. Most of the work is promoting and enforcing the guidelines. Try to get the time, budget, and organizational support for that.

Example Style Guides

For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, Gnome) for the organization, issues, and topics you may want to have. Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes have compliments for forms. There’s also guidelines for web sites, (e.g., usability.gov), but these will generally be less useful for applications.

What to Include

For the basic approach, see answers to How did you create design guidelines for your organization? To answer your specific question, I make a distinction between “elements,” or pieces of a UI (records, fields, layout, forms, command, and feedback), and “functions” (what some might call “patterns”), which assemble multiple elements into a standard UI for a common step in the user’s tasks (e.g., login, query, reports, undo, sort, zoom, help). I cover both in a style guide.

The idea of a style guide is to avoid you having to design everything yourself, so if a custom function only exists in one form, don’t include it in the style guide. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite.

The Deliverables

Ideally, the ultimate form of the style guide should be what works best for your users –not the tool/suite users, but the developers and designers that will use the styled guide to make the tool. A style guide should make their job easier, not harder. If it’s too hard for your users to find the right guidelines for a particular case, or learn and understand them, or implement them, they’re not going to. You can apply your UX skills to making the guideline deliverables by interviewing and observing your designers and developers to find out what will work for them (in your case, you may be limited to phone interviews with your developers; better than nothing).

This implies the product may employ multiple media. Chances are the “main” product will be some sort of hyperlinked document, which has obvious advantages for reference material. However, there may also be a summary quick reference guide or checklists, printable posters to promote the guidelines and highlight key features, a library of style-guide-compatible templates / patterns / CSSs, and seminars and workshops (possibly conducted remotely) for you to personally introduce the guidelines and show their advantages for the designers and developers. Frankly, creating the guidelines is only the start. Most of the work is promoting and enforcing the guidelines. Try to get the time, budget, and organizational support for that.

2 Addressing questions below
source | link

Example Style Guides

For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, Gnome) for the organization, issues, and topics you may want to have. Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes have compliments for forms. There’s also guidelines for web sites, (e.g., usability.gov), but these will generally be less useful for applications.

What to Include

For the basic approach, see answers to How did you create design guidelines for your organization? To answer your specific question, I make a distinction between “elements,” or pieces of a UI (records, fields, layout, forms, command, and feedback), and “functions” (what some might call “patterns”), which assemble multiple elements into a standard UI for a common step in the user’s tasks (e.g., login, query, reports, undo, sort, zoom, help). I cover both in a style guide.

The idea of a style guide is to avoid you having to design everything yourself, so if a custom function only exists in one form, don’t include it in the style guide. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite.

The Deliverables

Ideally, the ultimate form of the style guide should be what works best for your users –not the tool/suite users, but the developers and designers that will use the styled guide to make the tool. A style guide should make their job easier, not harder. If it’s too hard for your users to find the right guidelines for a particular case, or learn and understand them, or implement them, they’re not going to. You can apply your UX skills to making the guideline deliverables by interviewing and observing your designers and developers to find out what will work for them (in your case, you may be limited to phone interviews with your developers; better than nothing).

This implies the product may employ multiple media. Chances are the “main” product will be some sort of hyperlinked document, which has obvious advantages for reference material. However, there may also be a summary quick reference guide or checklists, printable posters to promote the guidelines and highlight key features, a library of style-guide-compatible templates / patterns / CSSs, and seminars and workshops (possibly conducted remotely) for you to personally introduce the guidelines and show their advantages for the designers and developers. Frankly, creating the guidelines is only the start. Most of the work is promoting and enforcing the guidelines. Try to get the time, budget, and organizational support for that.

For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, Gnome) for the organization, issues, and topics you may want to have. Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes have compliments for forms. There’s also guidelines for web sites, (e.g., usability.gov), but these will generally be less useful for applications.

For the basic approach, see answers to How did you create design guidelines for your organization? To answer your specific question, I make a distinction between “elements,” or pieces of a UI (records, fields, layout, forms, command, and feedback), and “functions” (what some might call “patterns”), which assemble multiple elements into a standard UI for a common step in the user’s tasks (e.g., login, query, reports, undo, sort, zoom, help). I cover both in a style guide.

The idea of a style guide is to avoid you having to design everything yourself, so if a custom function only exists in one form, don’t include it in the style guide. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite.

Example Style Guides

For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, Gnome) for the organization, issues, and topics you may want to have. Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes have compliments for forms. There’s also guidelines for web sites, (e.g., usability.gov), but these will generally be less useful for applications.

What to Include

For the basic approach, see answers to How did you create design guidelines for your organization? To answer your specific question, I make a distinction between “elements,” or pieces of a UI (records, fields, layout, forms, command, and feedback), and “functions” (what some might call “patterns”), which assemble multiple elements into a standard UI for a common step in the user’s tasks (e.g., login, query, reports, undo, sort, zoom, help). I cover both in a style guide.

The idea of a style guide is to avoid you having to design everything yourself, so if a custom function only exists in one form, don’t include it in the style guide. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite.

The Deliverables

Ideally, the ultimate form of the style guide should be what works best for your users –not the tool/suite users, but the developers and designers that will use the styled guide to make the tool. A style guide should make their job easier, not harder. If it’s too hard for your users to find the right guidelines for a particular case, or learn and understand them, or implement them, they’re not going to. You can apply your UX skills to making the guideline deliverables by interviewing and observing your designers and developers to find out what will work for them (in your case, you may be limited to phone interviews with your developers; better than nothing).

This implies the product may employ multiple media. Chances are the “main” product will be some sort of hyperlinked document, which has obvious advantages for reference material. However, there may also be a summary quick reference guide or checklists, printable posters to promote the guidelines and highlight key features, a library of style-guide-compatible templates / patterns / CSSs, and seminars and workshops (possibly conducted remotely) for you to personally introduce the guidelines and show their advantages for the designers and developers. Frankly, creating the guidelines is only the start. Most of the work is promoting and enforcing the guidelines. Try to get the time, budget, and organizational support for that.

1
source | link