Our Design Process at Ncontracts

If you’ve ever been curious about what a design process is, you might have come across this general process:

  • Define the problem
  • Conduct research
  • Brainstorm and conceptualize
  • Prototype
  • Test
  • Improve

The design process helps break down a project from ideation to execution into digestible steps that allow any team to solve complex problems and create solutions that work best for their users.

Despite it being called a “design process”, the process itself doesn’t just involve designers. It involves product/project managers, developers, and quality assurance analysts too.



So what does this process look like at Ncontracts?

At Ncontracts, we follow a specific approach to agile called Dual Track Agile (which we’ve written about before). This approach ensures that our team stays connected throughout the lifecycle of a project while allowing us the flexibility to change the direction of a project if need be, compared to other approaches.

We categorize our design process into two main phases – Discovery and Delivery. Each phase includes multiple steps that require a team effort, involving at least two or more teammates during each progression. Similar to design, this process may be adjusted based on the situation. Steps may repeat more than once, and the process itself is one that we aim to exemplify throughout our product teams.



The Ncontracts Design Process

Phase 1: Discovery

The goal of this phase is to achieve a shared understanding of:

  • What the problem is that we’re solving (Objectives)
  • Who we’re solving it for (Personas/Roles)
  • What we want to achieve (Outcomes)
  • How we think we can achieve it (Solutions)
  • How we’ll know we achieved it (Measures/Metrics)
A) Initial Understanding

When a problem has been introduced to the team, we kick off the project by having the product manager, lead product designer, and lead developer gather as much information as possible. This includes laying out our initial understanding of the problem we’re trying to solve for, who we’re solving it for, documenting any known pain points, assumptions regarding the problem, and defining criteria for success. Our definition of success is based on insight from customer and subject matter expert (SME) interviews, data analytics, and conversations with the leadership team and stakeholders.

In order to retrieve this information, the involved parties conduct interviews with customers and SMEs to create personas. The tools that are used include a Lean UX Canvas for documentation, a Kanban board to keep track of our progress, and analytics tools to gather user data regarding our products.

You might ask “why doesn’t this step involve others on the team?”. This step makes it easier to communicate these consolidated findings to the rest of the team while allowing the other team members to continue working on other projects at the same time (remember, we’re using a Dual-Track Agile approach here).

B) Shared Understanding

Taking the documented insights and information, the problem is now presented to the rest of the team. Other teammates have the opportunity to ask questions and get clarification on what we’re trying to solve, who our target user is, and have a rough idea of how our solution will benefit our users. This is where our Kanban Board and Lean UX Canvas come in. The entire team can easily view the consolidated information, where we may continue clarifying with journey mapping sessions, design sprints, and discuss any additional personas that are necessary.

We do this to bring awareness and collectively understand the problem, user needs, and findings from the previous step. This also incites beneficial discussions and team collaboration.

C) Identifying Solutions

Next, we start to brainstorm possible solutions with the success criteria and an appropriate timeline in mind. To come up with solutions, we use rapid ideation methods, conduct competitive and user research, and have user story mapping sessions. Sometimes projects also come with an assumed “best solution” – this is the time to challenge that assumption and leverage ideas to create a better solution. This step is also a great opportunity for every team member to voice their opinions, question the work that we’re doing, and ask ‘why’. Solutions are narrowed down based on what the entire team believes to be the best for our users.

After the team discusses and agrees on a single solution, the project is “sliced” into smaller, attainable deliverables that outline the specific efforts and elements necessary to design and develop. This is the assigned designer’s cue to continue defining the details of the solution through sketches, mockups, and UX artifacts. Once the designer has UX mockups to present, the team can move on to phase two of the design process.



Phase 2: Delivery

The goal of the delivery phase is to build out, test, and assess how well the solution is being implemented while maintaining communication with the team.

D) Development & Design Alignment

Now that the solution has been refined even further, the designated developer joins forces with the assigned designer(s) to discuss the appropriate design criteria, clarify any questions the developer may have when executing the design, and revise design mockups if necessary. Designs are also iterated upon based on technical considerations.

Mockups, clickable prototypes, and our Ncontracts Design System are used often as references throughout this part of the process, while we use our Kanban Board to keep track of our progress throughout development.

E) Over-the-Shoulder Reviews

As the developer moves forward with executing the design, the developer and designer meet up frequently to review and evaluate the progress on the development side. We call these reviews “over the shoulder reviews”. During these reviews, they discuss any possible roadblocks when building out the design. Additionally, the designer can identify any details and design specs that deviate from the original design criteria. Developers should use this opportunity to showcase their work as they build out the solution. Designers can ensure that the implementation aligns with the original design vision and help developers to efficiently remain on course. These reviews can and usually occur often until both the designer and developer are satisfied with the result.

F) Checking the Test Environment

Before the new solution is placed in front of our users, the developer deploys it into a testing environment. Quality Assurance (QA) and development work together to double-check that the design has been implemented properly while also being functional. Designers and product managers are also encouraged to check out the test environment. The environment can be tested multiple times to confirm whether the final product is up to quality standards before the official launch.

G) Final Production Check

Once the developer gets the OK from QA and deploys the new design solution into the user-facing product, the live product is also assessed to ensure that users are not having any functionality issues. Assessing the product post-launch is crucial in order to understand if our users are having technical issues after this implementation. We can then continue collecting data from our users to discover any new pain points and identify areas of improvement as they use the product.



How does this process benefit us?

By following this design process and utilizing a Dual Track Agile approach, we’ve been able to achieve success in more ways than one. Not only have our teammates stayed connected throughout each step of a project’s progress, but we’ve been able to address our users’ pain points more effectively with diverse perspectives and iterate upon solutions more efficiently within time constraints. What truly makes this process work is the essential collaborative effort from each team member – it only works so long as everyone is actively involved and keeps up communication. That being said, at Ncontracts we’re always looking to improve our process and ensure that we keep our users’ needs in mind.

If you work at an organization that follows a design process, how does your process compare to ours?