Releases and Deliverables

Rasmus Hedin

Versioning (in software production)

During the process we use a versioning system that’s called “Semantic Versioning” (or semver https://semver.org), the version number gives hints of where in the process the product is and the quality but doesn’t tell the whole story.

Production Milestones

In Semver there is room for special names to clarify the quality of certain versions, typically this is used when the end result is expected to be ‘production quality’. It is possible to have different features reach different maturity but typically the names are for the whole product.

Released Product

  • Can be released/sold/sent out/marketed
  • There could be bugs but these should be minor
  • Performance needs to be solid

Release Candidate

  • A version carrying the expectation (hope) that the product (feature) is good enough to release
  • Sent to extensive testing
  • Bug reports are Very important, if major problems are found the candidate was not good enough and typically a new candidate (RC2 et.c) is made

Beta Release

  • A particular feature or the whole product is mostly done
  • It can be tested from all angles
  • Testing and bug reporting is important

Alpha Release

  • A particular feature (or the whole product) is partly complete
  • It’s enough to test from some angle
  • Reporting minor bugs is not meaningful

Outcomes/products/deliverables

Product Quality

(Full) Product

A Product is something that is considered having production quality and fulfils all agreed features

  • It should have a version of at least 1.0.0 when done
  • It is typically used by – and maybe sold to – (many) users
  • Users can be expected to report bugs and get support
  • There should be processes in place that control the quality before released to users
  • Releases should have tests, readme:s and usage instruction
  • Typically we hand over code in a cleaned and usable state (without version history)

Minimal Viable Product

  • Minimum: the smallest set of features, and infrastructure that…
  • Viable: deliver enough value that customers are willing to invest…
  • Product: on something they can use today…

Working with MVP is a philosophy and many products/projects never aim to reach MVP

  • When an MVP is released it should have reached production quality
  • An MVP provides value to customers that uses it (as opposed to just test it)
  • An MVP should be stable and thus have a version of at least 1.0.0
  • An MVP typically does have limited settings/modes/adjustments
  • An MVP works well at what it does and appeal to early adopters

Prototype quality

Prototypes are meant to be thrown away and not delivered as part of the final product. That emphasis is often necessary; otherwise project managers may get the impression that it’s good enough to ship just because it looks like it works.

  • a prototype is made to show or test either part of the system or the entirety
  • a prototype can be made of all kind of non functional (static) parts

Tech Prototype

  • a prototype can be made to look polished but all kind of shortcuts are allowed
  • it’s not meant to represent the final product and it’s usually better to make it look rough
  • no part of a prototype should be assumed to be transferable to real product development
  • a prototype should never reach 1.0.0 in version
  • If we show/give prototypes to the customer it is “as is” (preferably only in a compiled form).
  • Typically we do not hand over the source code at all.
  • Software can not be expected to be commented or tested and public readme:s or build instructions might not be present, whether for our later selves or customers.

Design Prototype

  • no technology is involved.
  • it’s composed of mockups that have been linked together, with potentially animated parts, to showcase the look and feel of a future product (or a concept)
  • mockups can be as rough as wireframes or using real design
  • it is not functional and typically never for the entire product (usually for the main user paths)
  • its main purpose is to visualize the different interactions and paths the user can perform and take in a product
  • the 2 use cases of a design prototype are:
    • concept validation by the client
    • user testing to find design quirks early on

Full prototype

A technical prototype where the design is made of a combination of real design elements and mockups.

  • will both look real and behave like a real product
  • Usually something we avoid as it can give the wrong impression of how far the project is

Proof of Concept

  • PoC should prove something (a use case, a technical solution, a design) as opposed to showing visionary material about how we think it could work
  • technical PoC has prototype quality yet combines several parts to evaluate feasibility
  • PoC could be the end delivery of a project, or a a prototype milestone part way to evaluate whether the full product should be made
  • PoC should prove that it is possible to connect the different components
  • For software all important (or difficult) APIs and libraries should be used/connected to, but no need to use all features in an API
  • For hardware the major components need to be somewhat connected
  • if PoC is a deliverable to the customer the contract and communication needs to specify what it is supposed prove and the level of quality that can be expected

Other design deliverables

Concept

  • The concept stage comes before the prototyping and proof of concept.
  • Concepts can be communicated with different tools: these could be more or less polished drawings, mockups, 3D renders, fake videos to show intent, storyboards, but that cannot be interacted with in the prototype sense. They are just static renditions to show how a thing could look like and behave, and are applicable to different end products, from websites to touch tables.
  • Sometimes more than one concept is made and presented in order to facilitate decisions on design directions.

Mockups

A mockup is used either to test the visual design/branding on top of the structure decided in the previous stage (wireframes) or to describe the design to stakeholders (or developers)

  • A mock-up is not a prototype. It is a high fidelity, static single layout/render of an interface or such with the branding of the client integrated on top of the wireframed structure. In the case of an application/website, a mock-up corresponds to one screen.
  • Mock-ups are generally high fidelity or pixel perfect, with the exact sizing, colors, fonts, dimensions as what will be developed later on in the process. The visual aspect of the final product should look exactly like in the mockups.
  • A physical mock-up would likewise be a polished, painted, real-size model that represents the feel and finish of the final product.

Wireframes

Wireframes are the stage before the mockups. While mockups are essentially a high fidelity static rendition of a layout with the final colors and visuals, wireframes are in black and white, and go from low fidelity (not detailed) to high fidelity (very detailed).

  • Their purpose is to decide on an application/website/interaction structure without being distracted by how it looks.
  • Wireframes are essentially titled grey blocks to define content structure.

Guidelines

Branding Guidelines

Branding guidelines are a set of rules to be followed regarding a specific branding delivery. It typically includes typefaces to be used and their replacements, the logo in color and black & white, the color scheme, mission statements, image examples on how to apply the branding to pictures, leaflets and roll-ups (or any other relevant advertising devices), as well as do’s and don’ts.

Digital Guidelines

Digital guidelines are similar to the branding guidelines but more specific to a digital product: it will include typefaces, colors, icons, specific components like buttons and menus with their sizing, behavioral changes, etc.

Research Reports

Reports content can vary depending on the goal of the research, but such reports are usually divided into 3 parts:

  1. User testing / user research. This part typically includes gathering a set of users that will be interviewed, followed on their daily tasks, or who will test a prototype, product, concept, in accordance to the target area the client has underlined. It can also include only desk research, like a heuristic evaluation (a set of design principles that needs to be respected for good usability).
  2. Insights uncovered. The second part of the report gathers general statistics about the testing/research that has been performed, as well as key insights about the area.
  3. Recommendations based on insights. Thanks to insights, opportunities and problem areas are uncovered, and preliminary recommendations can be made in order to improve the existing product, or create one.

Words not to use for deliveries

Demo

  • A demo is the demonstration event of the product, or a feature or of the design on paper or some detail.
  • A deliverable is never called a demo

Sketch

  • A sketch is made to try out a thought on paper, physically or with code
  • A sketch is usually not meant to be shared outside of the team
  • If there are several different designs to show to decide on directions we name them Concepts (see above)