Jumping in Mid-Project (Insights from a Designer)

by
Tags: , ,

Man jumping into water from cliff

Intro

Joining a project after it has already started is no easy task, especially when the project is launching a complicated enterprise application with a short deadline. Here are the take-aways from my experience when I was hired to join a team and lead design halfway through the build of an e-commerce site.

Getting Started

I needed to hit the ground running which meant catch up to everyone on the project at the same time as designing revisions and new features. When I started, the project had been underway for nearly two years and had some developed features. The work in progress needed to be reviewed and questioned because some of what was done was based on poorly communicated direction or the client had revised the requirements. There were also new features that the client considered must-haves that were not yet discussed, so there was a lot more work to do.

Learning The Client

Knowing how to collaborate with your client is vital no matter when you join a project. This requires knowing: 

  • Their level of understanding software development
  • How to present designs to them
  • How to gather business requirements from them
  • What is important to them from a design perspective

I found when joining mid-project that I also needed to know:

  • What was the design process that they were used to
  • If the already completed work met their expectations

Learning The Business

It’s always necessary to know the client’s products, how they make money, and who the customers are (beyond looking at their website and competition). Usually, projects start with a discovery phase to understand the business and how users interact with it, but I was joining well after this phase. I found the best way to really understand the business was to discuss existing designs with the client and question the decisions along the way. By doing this, it ensured that the designs reflected business needs, and that the client understood design decisions. This communication got everyone on the same page, so the client felt a sense of comfort and control with the end product.

Learning The Team

Knowing how to work with the development team is crucial to any project’s success. What types of requirements and design files are needed to develop the product efficiently varies by project, team, or even team member.

For me, the main difference when joining mid-project was that the developers knew the project much better than I could learn in a short period of time. This was helpful when I needed an answer about the application, but it led to confusion when what the developer knew was different from what the client wanted. Finding the best way to articulate and discuss requirements to each unique team member was integral to the success of the project.  

Learning The Work In Progress

Joining mid-project meant a partially functioning app had already been developed. In the interest of time, it was important to leverage what had already been done when implementing new features. Also, we obviously did not want to redo work, which meant avoiding changes to the system architecture or technologies if possible. Understanding the level of effort of changing the pieces of the existing app was crucial to being able to make design recommendations that met business needs while limiting redundant work. 

Putting It All Together

Getting up to speed takes time. Even though I was designing new features from the start, it wasn’t until I had a firm grasp on the previous points that I was able to create a better process. Designing the process is often more important than designing any screen or flow because there are so many variables when working on a project at this level. Knowing how to keep all parties satisfied and accountable allows for things to run smoothly because, in reality, requirements will always change, but being able to gracefully handle new situations is the key to success.