Skip to main content

Writing Concepts

As you’ll discover later, the speed of onboarding, and the post-onboarding learning curve are essentially governed (and can be predicted) by the number of concepts (and actions) you have.

This is how I write concepts when I design software, please adapt this to whatever works well for you. Strip out the parts you don’t like and add any sections that your particular problem domain requires.

To begin with, each concept has several sections:

Purpose​

A brief description of what the concept does.

States​

Possible conditions, settings or modes in which the concept can exist (e.g., on, off).

Generally speaking states do not add, in any meaningful way at least, to the difficulty of using your app (unlike Actions). So if you can add a further state to an existing concept rather than adding an entirely new concept, that’s the right way to go.

Example Use Cases​

Example scenarios demonstrating the concept in action, providing a clear picture of its utility.

Operational Guidelines​

  • Default State: The concept's initial condition upon introduction.
  • Usage Rules: Do’s and don’ts governing the concept's use.

Actions​

A list of interactions or operations that users can perform with the concept.

Actions do add to the difficulty of using your app. The trick here is to keep the list of actions you can do as small as possible across your app. Actions should be checked for duplications in the same way that concepts are.

Accessibility Considerations​

Ensuring the concept is usable and accessible to all potential users.

Safety/Misuse Considerations​

Identifying potential areas of abuse and implementing safeguards that may revolve around bad actors, or data security.

Highlighting connections to other concepts to prevent duplications, contradictions, and confusion.

Notes​

Additional remarks or rationale explaining certain design choices or preferences and importantly any rejected ideas.

tip

Try not to include any user interface details in your concepts, details of organisation are fine (this will help inform the Information Architecture) but keep things like checkboxes and menus out as this will just restrict processes further down the line.

οΏΌ

Example Concepts​

Here are some hypothetical Concepts for a simple photo editing app to give an idea of how I go about this.

Album

Purpose​

An "Album" organizes a collection of photos, allowing users to easily browse and manage their photo collections based on themes, events, or personal preferences.

States​

  • Default View: Displays photos in a grid within the album.
  • List View: Shows photos in a list format, with thumbnails and brief details.
  • Favorites-Only View: Displays only photos marked as favorites within the album.

Example Use Cases​

  • A user creates a family vacation album, grouping all relevant photos.
  • A user filters their wedding album to view only their favorite photos.

Operational Guidelines​

  • Default State: Grid view displaying all photos.
  • Usage Rules: An album should not exceed a certain number of photos to ensure smooth scrolling. Albums should be deletable, with a confirmation prompt to prevent accidental deletion.

Actions​

  • Create Album: Users can create a new album with a name and optional description.
  • Delete Album: Users can delete an album, removing the group without deleting individual photos.
  • Add/Remove Photos: Users can add or remove photos from an album.

Accessibility Considerations​

Ensure album navigation is fully keyboard-navigable and provides text-to-speech support for screen readers, with photo descriptions accessible through ARIA labels.

Safety/Misuse Considerations​

Provide clear warnings before deleting an album. Also, prevent users from accidentally duplicating photos within the same album.

  • Photo: Photos within an album link back to their original instances in the app's library.
  • Info Panel: Users can access a photo’s metadata and options directly from within an album view.

Notes​

Consider the addition of shared albums for collaborative viewing and editing.

Photo

Purpose​

A "Photo" represents an individual image, which can be edited, tagged, and organized within the app.

States​

  • View Mode: Displays the photo without editing options.
  • Edit Mode: Enables image editing tools like cropping, adjusting, and filtering.
  • Share Mode: Prepares the photo for sharing with others, including resizing and format options.

Example Use Cases​

  • A user crops and enhances a photo before adding it to an album.
  • A user marks a photo as a favorite to quickly find it later.

Operational Guidelines​

  • Default State: View Mode.
  • Usage Rules: Only one edit mode should be active at any time to prevent conflicts. All edits should be reversible through an undo function.

Actions​

  • Edit Photo: Access various editing tools to adjust brightness, contrast, and more.
  • Mark as Favorite: Users can mark specific photos as favorites for easy access.
  • Add Tags/Keywords: Users can add descriptive tags for quick search.

Accessibility Considerations​

Provide high-contrast and alternative text options, ensure keyboard shortcuts for all actions, and make tooltips accessible for descriptions of each editing tool.

Safety/Misuse Considerations​

Implement non-destructive editing to prevent accidental loss of the original photo. Add a reset button to return the photo to its original state.

  • Album: The photo can be grouped into one or more albums for better organization.
  • Info Panel: Metadata about the photo, such as tags, favorites, and comments, are accessible through the info panel.

Notes​

Consider enabling multiple selection for bulk actions, like tagging or favoriting multiple photos.

Info Panel

Purpose​

The "Info Panel" provides detailed information about the photo, including metadata, location, comments, and keywords. It also allows users to mark a photo as a favorite.

States​

  • View Only: Displays metadata without edit options.
  • Edit Mode: Allows users to edit metadata, add comments, keywords, and location data.
  • Compact Mode: Displays minimal information for a quick overview.

Example Use Cases​

  • A user views the capture date and camera settings of a photo.
  • A user tags a photo with keywords like "nature" and "sunset" to facilitate search.
  • A user assigns a specific location to a photo taken on a trip.

Operational Guidelines​

  • Default State: View Only.
  • Usage Rules: Metadata should only be editable in Edit Mode. For accurate geolocation, users should confirm location data to prevent errors.

Actions​

  • Add/Edit Comments: Users can add personalized notes or comments about the photo.
  • Add/Edit Keywords: Users can add tags or keywords for easy searching.
  • Assign Location: Users can set or modify the location associated with the photo.
  • Mark as Favorite: Users can mark or unmark the photo as a favorite for easier access in albums.

Accessibility Considerations​

Ensure all metadata fields are accessible with screen readers and provide keyboard shortcuts to switch between view modes.

Safety/Misuse Considerations​

To avoid privacy issues, add a prompt or setting to disable location sharing. Prevent the accidental overwriting of original metadata by adding an "undo" or "revert" option for each change.

  • Photo: The info panel displays metadata for the selected photo.
  • Album: The info panel is accessible within the album view for individual photos.

Notes​

A future addition might include "sharing metadata," allowing users to selectively share only certain parts of metadata when the photo is shared externally.