Product Development Processes

Home

The process has you

Welcome back

Follow along as we describe each of our 13 processes and their place in our development cycle through a project to product client questionnaire, the concept we're about to demonstrate applies for any work scope, from a single component to a fully-blown web app.

How does it work?

The requirements process:

Easy, you contact us, we schedule a free online introductory meeting where you can tell us about your project and help us understand your requirements, with the info and ideas you'll give us we will make the product requirements document (PRD), at the end of this process we will have a record which we will base upon our initial time estimations, this document will also help us define the scope of work when we later divide the requirements into deliverable units of work.

I like it that we're clear about my requirments, how do we start?

The architecture process:

We're going to write a system design document (SDD) which will specify the overall chosen architecture for the product. At the end of this process, we will have a paper describing the chosen tools, their relationships, tradeoffs, and how they provide the desired level of reliability, salability, and maintainability.

Illustration for I like it that we're clear about my requirments, how do we start?

Nice, we mapped all the necessary parts, but how will it look and feel?

The wireframe process:

We'll draw a freehand sketch which we will base upon the PRD. It will roughly represent the components that make the user interface (UI) and will be served over a shared location to collect your inputs and suggestions. At the end of this process, we will have an agreed-upon wireframe of the product ready to be turned into a design.

Illustration for Nice, we mapped all the necessary parts, but how will it look and feel?

Made the concept, how do we bring it to life?

The design process:

We take the wireframe and convert it into design screens, colorful schemes, typography rules, and interactive prototypes. These resources will be served over a shared location to gather on-going feedbacks, and at the end of this process, we will be able to visualize the entire product.

Illustration for Made the concept, how do we bring it to life?

Beautiful, It looks and feels exactly as I imagined, how long until I can show it to my friends?

The user stories process:

To estimate delivery, we convert the PRD, SSD, and the designs into deliverable units of work called user stories. These stories will have a clear definition of done, an associated list of the required tasks needed to complete each story, and an assignment of a time estimation per task. At the end of this process, we will be able to calculate the necessary time needed to complete each story by summing every task time estimations.

Illustration for Beautiful, It looks and feels exactly as I imagined, how long until I can show it to my friends?

'It makes sense; we have everything written into deliverable units, but how can I monitor the progress of those stories?

The log process:

We believe in transparency all the way so we connect all of our processes logs into a dedicated chat environment where we can inspect every moving part of the product development cycle, at the end of this process you'll be able to get detailed real-time notifications as stories progress.

Illustration for 'It makes sense; we have everything written into deliverable units, but how can I monitor the progress of those stories?

What about inspecting the execution of designs?

The storybook process:

We do this with a shared components playground, which we'll populate as we complete each component and it's associated story, at the end of this process you'll be able to compare the execution level of each element to its original design specification.

Illustration for What about inspecting the execution of designs?

And how can you assure me that everything will behave as expected?

The test process:

We specify the minimal passing requirements for each component to be called "working" and write tests against those requirements, at the end of this process we will have a set of failing tests for all of our components.

Illustration for And how can you assure me that everything will behave as expected?

Mhmm...wait, what's the point? Just write the code and test it afterwards...no?

The code process:

With this approach we get a clearly defined goals in the form of failing tests which we only need to write code against until they check, it keeps us focused and goal-oriented, at the end of this process we'll be able to deploy our system and test its behavior in a dedicated environment.

Illustration for Mhmm...wait, what's the point? Just write the code and test it afterwards...no?

It all sounds cool and all, but where all of this happens?

The deploy process:

It all happens in the version control, aside from recording every single code change and have the ability to come back to it on anytime, we can also use it as the source for our deployments, at the end of this process you'll be able to preview the entire project with its current code changes\version on a dedicated preview link before we release it to a live production environment.

Illustration for It all sounds cool and all, but where all of this happens?

And we need this because it helps us do what?

The quality assurance process:

Well, we are humans after all and we all make mistakes, this extra step allows us to fine-tune any bugs we might find and assure that expectations meet reality, this step is the final approval point before delivery, at the end of this process we will be able to release our code into a live production environment.

Illustration for And we need this because it helps us do what?

Ok, everything looks excellent and functioning as expected, how do we deliver it?

The release process:

After the current version was approved we push it to a production environment using CI/CD pipelines, pipelines allows us to automate the entire release process into a single button, it will enable us to run all the test's we wrote up until that point as part of each release automatically, this process provides us an early bug detection mechanism which prevents faulty code from contaminating the live environment, if all pass then at the end of this process the version will go live, and users will be able to interact with it.

Illustration for Ok, everything looks excellent and functioning as expected, how do we deliver it?

Nice! But wait, what if I need something changed or added?

The repeat process:

In case you'll want to add a new feature or change existing one then all that's needed is a new user story for the required unit of work, once we have that we just run our processes against it at the same manner as we did up until now, this iterative approach allows us to adapt and deliver fast in the continually changing world of product requirements.

Illustration for Nice! But wait, what if I need something changed or added?

Ready to take your product to the next level?

we hope we illustrated a clear picture of our approach at this beautiful craft of making modern web applications if you feel you are ready to join us for the next cycle, then please contact by pressing the link below and let us invite you for a virtual coffee and a quick chat.

some of the processes demonstrated might be redundant in a scenario where you already manage a similar process of your own, which in that case, we will happily integrate with it.

Checkout our projects to learn about our accomplishments.
Contact us and we'll love to tell you more.