All our ideas about how customers were going to use our product were wrong. It was (and largely still is) chaotic when we started working with real customers and had to figure out how to tweak things that were already in motion. We have come up with a process titled the ‘Project Delivery Experience’. It represents the entire procedure from when the customer/client clicks “Start a Project” to when the finished product is handed-over. I will write about our entire design philosophy behind it once we are done perfecting it but for now, we think of it as more of an experience than a complete theory.
At the beginning of every Project Delivery Experience is the design process. What makes this difficult is the output and the feedback loop. There is a large possibility for things to go wrong because we work with some remote designers who are not used to structure and due process. A lack of structure and adequate management can make even the best designers seem unproductive.
First of all, it is quite difficult to explain the project that has to be done ( via Slack or some other VOIP tool) to the remote designers. Because design has a lot to do with perspectives, the information that has to be passed across to the designers can be as much nonverbal as they can be verbal. Using a medium of communication that is quite restrictive can hinder the process of properly explaining the project to the designers.
Secondly, the remote designer is using his own computer and resources so we don’t have access to the design file while it is in production. The lack of access restricted our ability to monitor the work being done as well as the progress being made. A lot of the time, we may just have to take the designers’ word for what has been done and it limits our ability to communicate changes that need to be made on the go. Waiting till some designated time to check the work and make corrections was a slow and inefficient procedure. All of this, can cause a serious problem if for some reason, something goes wrong and the designer is absent.
Thirdly, we had a problem with the designs being delivered to us and in a case where a collaborative designing effort was required, it was difficult to quickly tweak the work and move forward. We needed a seamless process and workflow to ensure quality. While this sounds very basic, it required a lot of things to go right and for us to meet our self-imposed timeline of one and a half weeks.
Also, there’s the client. If you depend on the client to give you feedback at his/her own pace then you’re going to be on the project forever. The client is always thinking of new things to add and new ideas keep coming up every day. This is not a good thing because time wasted on reiterating specific points, is literally money wasted.
We needed to hack up a systematic way to make it work. Every step of the process is thought of as a system with carefully crafted timing and expected deliverables. I’ll share with you, the first version of how we get the work done, starting with a design sprint. We could either design the entire app holistically or decide to design and ship in crunks depending on the size of the product.
How Do We Keep to Our Schedule?
Product design ships between 1.5 weeks – 2.5 weeks. This is usually the toughest step because we take the client’s ideas and make it visual for the first time. A couple of things go right here; the product owner/client is able to see what the app will look like and make adjustments very quickly. To make sure this goes well for everyone involved, we employed these simple tools:
Design in Sketch
Integrate Sketch with Zeplin
Invision/Material Gallery for prototyping and feedback
Files are synced in a Devcenter Dropbox Folder
The process from payment to development flows as drawn below.
The designer leads the project at this point and is involved in the conversation with the client. Direct contact and conversations keep up the momentum and reduces communication errors. Also, during this time, the PM shares the work to be done in high level with the developer(s) working on the project to keep everyone on the same page.
What happens when there’s no content?
Most projects we receive are web/mobile applications with a one to five pager front-facing website. We build the content for the website and check it with the client while the core application is being developed. We have a bunch of remote content writers that come into the conversation at this point who make the process of creating the content a lot easier and provide a diverse perspective on the ideas.
How we keep quality in check?
First, there is a ‘Designing the Devcenter way’ rule book. It’s a rulebook for designers on the Devcenter platform. It is a work-in-progress but we are gradually getting there. The document highlights these few things:
Tools and workflow
Rule of engagement
Time and Asset Management
Secondly, we run an extensive internal check on the design to see that it meets the requirements. We are already exploring different ways to have a remote quality assurance process using other Devcenter remote Talent.
Are we there yet?
The honest answer is ‘Almost’. I’ll say pretty close but there’s a lot more work to be done. Our goal is to use technology to automate the design process, ship product at speed, and do it better than everyone else. I hope this gives a basic idea of how we have made design sprint work at Devcenter.
You can reach out to email@example.com if you have any questions or comments and we’ll do our best to get back to you timely.
Thanks for reading!