Core Application Design Process

**UPDATED AND FINALIZED

TLDR process is:

  • Feature/process is defined as a markdown file, in the feature definition repository within a directory structure as follows:

         process_name 
          |- process_name.md
          |- process_name-hifi-V1.jpg
          |- process_name-fms.jpg
          |- feature_name
               |- feature_name.md
               |- feature_name-hifi-V1.jpg
               |- feature_name-fms.jpg
          |- another_feature_name
    
  • Everything will live in the feature definition repository. A feature/process will be present both as a directory in the repo and also as a card in the project kanban in the same repository. This kanban is used to identify where in the current process the feauture or process is

  • Use cases can be created by contributors by either creating an issue or submitting a PR. The contributing.md will describe things like format of the markdown file and also where to get information on the MVP feature definition prose.

  • Completed use cases get assigned to @cellio or @mattjbrent for approval

  • Fat marker sketches are created in Figma in a closed environment. Suggestions or ideas can be posted as issues in the repo, clearly tagged with the appropriate information.
    *Fat marker sketches are submitted to @mattjbrent and/or @cellio final approval for a process is signed off by the tech group leads.

  • Once approved, fat marker sketches are handed off the back end dev for technical consideration and implementation

  • high fidelity designs will be created in Figma in a closed environment. Suggestions or ideas can be posted as issues in the repo, clearly tagged with the appropriate information.

  • Hi fi designs get approved by @mattjbrent for design. At this stage, it should just be visual and functional/technical considerations should have already been approved.

  • Once approved, they get handed off to front end dev for implementation

We will work on global processes and features first. This will allow back end and front end to create something visual and allow for setup of routing etc. This will also define the basis of our design language (typography, color, spacing etc)

Once global process is finished (including hi-fi designs) we can move on to speccing out all of our other processes and features. All our effort should be put into getting the gobal processes defined and complete so that all of our devs can be unblocked and productive, working on approved designs. Once each team has finished their aspect of global elements, they can assign other members of their team to contextual processes and features.

We have started the authentication and signup process as a simple working example before starting work on the global processes and features. This will act as a working documentation for the process.

For some more info - read on

Final Design Process
For the sake of feature identification and process, see the app as being divided into 2 sections:

scoped features and processes, and global features and processes.

What is a process?
A process is made up of multiple features and acts as the parent that binds the features together. A process defines the UI elements that allow a user to accomplish a certain task like answering a question or searching for a specific question

What is a feature?
A feature is the building block of the app. A feature defines one action or interaction that the user can take. A user might interact with multiple features in one process.

What’s the difference between scoped and global features/processes?
A scoped feature or process is one that only exists in a particular context. This will represent the majority of our features or processes. A global one exists outside of any particular context and is the same across al instances (although an instance can contextualize features within a global process) A good example is the user menus, although might contain some contextual features, the process is global.

SUPER DUPER IMPORTANT: remember, we are talking about user behaviour and interaction here - not a 2D design. These interactions will of course eventually end up as designs but they have to be seen as they will be seen by the user. As things ‘to do and use’, not as things to see.

Feature/process definition and process
All work will be carried out in the same 3-stepped process. Each one of these 3 steps require approval before moving on to the next step. This approval is passed by either @cellio or @mattjbrent. This ensures any new feature or process achieves our functional requirements. @ArtOfCode, @kieran, @Marc.2377 or any other group lead can veto this approval if there are concerns over this, although this will be used only when necessary.

  • Using the identified functional specification, describe how the feature or process will work. This is called a use case
  • Taking the use case, define a fat marker sketch (also known as a wireframe) to outline the general gist of the feature or process. These define function and not aesthetic.
  • Taking the fat marker sketch and use case, create a high fidelity design.

This process is waterfall in nature, however each feature or process can be worked on simultaneously.

Use case description
Once a process and its features are defined, use cases are then developed. These are non-formal prose that define and describe how an MVP feature/process works. Its vital because it directly defines the requirements for that feature to be counted as successful. Use cases are currently on the project board in the docs but this might be subject to change. This is led by @cellio and its recommended that the docs contributors get heavily involved here.

Location: Feature definition repo (to be created). As markdown files. New use cases can be proposed as issues or as PRs. These are in the form of markdown files and follow a set structure (see the authentication example) TODO link.

fat marker sketches/wireframes
Once we know what the feature/process will contain and how it will work, a series of illustrations are created defining in very broad strokes how the aspects of the features work and fit together. This is less about aesthetic but more about what and where. They are line drawings that contain no color but should clearly identify visually the different aspects of the process.

Final, approved fat marker sketches exist in Figma, public link is posted either in the card in the feature definition repo project or in the MD file for the corresponding feature in the same repo. An exported jpeg will also be added to the repo in the corresponding feature/process directory once approved. Change requests, ideas or new fat marker sketches (formal illustrations or non-formal sketches) can be proposed in issues. Please don’t PR as all fat marker sketches will be created in Figma to keep everything in the same format and also for posterity’s sake. Ideally these issues would be clearly tagged to be identified as fat marker sketches.

Design
After the fat marker sketch is signed off, a feature will be put in a holding pattern until all the features in a process (and the process itself) is signed off on. Once a process is signed off, it can be handed off to back end to start working on any required logic before working on templates/razor.
Once signed off, we will start creating high fidelity designs for the process. This will be done formally in Figma under the Codidact account. High fidelity designs will be versioned and added as jpegs to the corresponding process/feature. The community can provide feedback in the format of issues in the feature definition repo. At this point, any feedback that is deemed to be actionable will be done so within a future release cycle.

Once high fidelity design is complete, front end can implement a pixel-perfect implementation :wink:
|
|
|
|
|
**ORIGINAL POST
After some discussion between myself and @cellio. We came to consensus on an approach for moving our list of defined required features for MVP into actionable items so we can really get the ball moving. It’s still a little loose at this point an some details of how it will work will likely change but the general gist is set.

The general app is divided into 3 sections: features, processes and global.

Defining features will be the largest part of this work. A process holds a number of features cohesively together. Global is a set of features or processes that exist globally (in all contexts). Consider the following example:

  • The navigation menu is a global feature
    The navigation is a feature/process that is available everywhere within the app and is not contextual

  • Answering a question is a process
    Answering a question contains many features to arrive at the final desired outcome

  • The markdown editor is a feature
    It exists within a process (or processes)

Our approach starts at a global level. This is used to create the direction of the design moving forward. Its defining some global features/processes but doesnt intend to be finished at this stage. This will likely look like the menu and overall structure, what buttons and links look like, colour pallete typography etc. All things that exist outside of a single process or feature. This follows the process of feature definition, use cases, fat marker sketch and then high fidelity designs.

Our approach then will move to the process level and is worked on a feature-by-feature basis. Each feature process is waterfall in nature but each feature is worked on independently. At a certain point (discussed later, each feature is paused. The work completed on the feature contributes to completing the process to the same level.

Once this point has been reached on a process a high fidelity design is created for the process and all dependent features. Processes can be worked on independently but have to be fed from the global design elements defined in the previous process.

This process will allow devs to create markup from the completed and signed-off wireframes/fat marker sketches and allow FE devs to add basic CSS so the app can be used. This will mean that there is as little blockage as possible between disciplines. Following this, we can also ensure all features are cohesive and ‘fit together’ thematically.

So the process is as follows:

define process and/or features
A process and its features get defined/assigned to work on. A feature could be small like authentication process or it could be a large process, like answering a question. For processes, they should be broken down into features which are treated independantly but kept under the umbrella of the parent process.

A good place to get an idea of what our process and feature list will look like is to look in the functional specification

The order of feature work will be defined and decided upon by @cellio and @mattjbrent. They will be created as cards on the project board in the docs repo and then converted to issues as they progress.

The first process and features are already defined: the authentication/signup process

Each process will be given a project leader to run and look after the corresponding tickets/issues. Contributors are encouraged to freely comment and work on these but it has to be through the project leader of the feature development. All final decisions will rest on @cellio and @mattjbrent in regards to content and approach with the caveat that @ArtOfCode or @Marc.2377 or @kieran can veto based on technical or feature conflict.

This way all contributor advice/work is welcomed so decisions are not made in isolation but there will still be agency within the team to cut through the likely strong opinions and get to a solution then implement. Ultimately we can’t listen to everyone’s conjecture and opinion and a decision needs to be made at some point.

The likely hood is that there will be compromises throughout this process from different contributors but the process should allow contributors the peace of mind that they are welcome to propose solutions, raise questions and concerns and know they are involved in the process of creating Codidact.

Use cases
Once a process and its features are defined, use cases are then developed. These are non-formal prose that define and describe how an MVP feature/process works. Its vital because it directly defines the requirements for that feature to be counted as successful. Use cases are currently on the project board in the docs but this might be subject to change. This is led by @cellio and its recommended that the docs contributors get heavily involved here.

fat marker sketches/wireframes
Once we know what the feature/process will contain and how it will work, a series of illustrations are created defining in very broad strokes how the aspects of the features work and fit together. This is less about aesthetic but more about what and where. They are line drawings that contain no colour but should clearly identify visually the different aspects of the process. It doesnt define specifics but generalities.
These currently exist in figma and will be created formally by graphic design contributors. They can however be suggested in any non-formal format (scribbles or more formal illustrations) by any contributor and will be taken into account. We still need to figure out the best format to have these openly available and then to capture requests and comments from contributors. Figma has the option to display designs publicly but we need to figure out a place to capture comments on a feature-by-feature basis.

Approval process
These fat marker sketches are then reviewed by the project lead of the feature. At this point the design should reflect all of the input from community and the contributors. They then get approved by @cellio and @mattjbrent to ensure they meet the quality and feature requirements for MVP. Each process will need to be signed off by a backend and frontend lead (project or group lead).

This process will take place in issues unless a better format can be provided.

Design
After the fat marker sketch is signed off, a feature will be put in a holding pattern until all the features in a process (and the process itself) is signed off on.
Once signed off, we will start creating high fidelity designs for the process. This will be done formally in Figma under the Codidact account however the process will be very similar to the fat marker sketches, contributors are encouraged to provide their own ideas and designs. Communication will work the same way as defined in the fat marker sketches when this is decided upon.

The high fidelity designs of the processes will also be simultaneously contributing to the informal design guidelines of the app. Most of the global aspects of this will already be designed in the global definition and design but it is likely that things might change slightly or new things be added as high fidelity design is progressed.

Features will become building blocks and might be in more than one location.

This is where my brain is at right now around process. Ive thought hard about this for the past few days now - ive drawn on a lot of my experience developing and designing apps and i really believe this structure is more-or-less the right approach for us to be successful. It might seem detailed but it needs to be. We need to ensure that we are opening collaboration up but at the same time locking down a process so that final (and correct) decisions can be made effectively and in a timely manner.

This is not canon at this point as im wanting so feedback but I will be finalizing this reasonably shortly (probably a couple of days) so please share your thoughts now as this is sorely needed to get things moving.

9 Likes

There are many parts of this process that I am interested in and excited about. I’ve been a pretty active contributor on the User Experience stack for a good 4 years, and I’d love to get involved with the feature design stages here, if I can be of any help.

What’s the best way for me to follow these design stages? Where should I be watching for these opportunities? Just by keeping an eye on the forum posts?


Edit (just reread it and found you mentionded the following):

We still need to figure out the best format to have these openly available and then to capture requests and comments from contributors.

I’ll stay tuned!

4 Likes

@maxathousand This now lives in a repo. The process is currently being formalized but will likely not change much. Check out this PR with this repo

3 Likes