How We Approach Design at Devcenter
A summary of the design processes we use and why we use them
Devcenter builds digital products for it’s clients using a remote pool of talented designers and developers. As such, we’re always looking for passionate and experienced people to join us. When asked why they want to join us, many of our applicants mentioned the opportunity to work on a wide variety of products and the option to work remotely as major factors.
Working remotely is great and all but with great power comes great responsibility. Remote work demands a level of professionalism and experience which at the moment we haven’t seen in many of our applicants. We measure these attributes by asking our applicants to submit case studies of products they have worked on, after which, we test them on a small project. This allows us to get a better understanding of our applicants capabilities and how they work.
While reviewing product case studies, we’ve noticed some issues which are common with quite a number of our applicants. We’ve seen; people design products that aren’t solving any problems and therefore not adding any value, portfolios full of landing page designs with no description of what value the products are meant to be adding to their users, etc
To get more designers to apply to join our talent pool, we held sessions in some Slack Communities (Devcenter Square, Figma_Africa and Forloop Africa) to chat with designers. During these sessions, we mentioned the type of designers were looking for, what we’re looking to see in portfolios and how the design team at Devcenter currently works.
We did this to guide potential applicants on the type of applications we’d like to see and possibly, get some feedback on our design process. A summary of our session is below.
There are certain things we look out for in design applications. For the most part, it’s some kind of process. Not just process but also the goals and results of the processes used and how the goals and results tie in to the overall product being designed.
We’ve seen a lot of people who are good at visual design but can’t really explain how the products they have designed are meant to meet business goals or add value to users.
Being good at visual design, in our opinion, is the easiest part of the design process. What’s more important is understanding the goals of clients and how their products can add value to users. In order to shed more light on this, I usually share a document that has helped me a lot in understanding what should be considered when designing products;
This is not to say all the processes mentioned in this doc must be followed extensively. We’re more concerned with the goals and results of these processes and not the processes themselves, so if you feel there are better processes you can use to achieve the same goals or get similar results please feel free to use them.
Below is a breakdown of how a typical design project runs at Devcenter, hopefully this will shed some light on why we encourage product designers to use these processes.
On-boarding designers to projects
Projects usually start with our Product Managers (PM’s) doing some research about; the problem that needs to be solved, users affected by the problem and the resources (time, people and tools) needed for the project.
The result of this is a Product requirement document (PRD) detailing the goals the client would like to accomplish with the product and the value the product should add to its users.
Once we have our PRD, we share it with the designers on the project and expect them to carry out a high level evaluation of the problem.
Clients often have an opinion on what product should be built to accomplish their goals but they aren’t always right.
If the client says he wants a mobile app and a website is that really the best solution? Can more value be added using other means such as; a USSD application, a Whatsapp bot or a Messenger bot?
It is the job of the designers to figure out how best to help the client accomplish his/her goals while adding value to potential users of the product.
If the client says he/she wants to build a custom app to, lets say, sell products. Can we make use of Instagram which already has a large user base and payment options instead of having to build a whole new app and acquire users? What is unique about this problem that requires a separate app to be built?
This is the kind of thinking we require at just the first step of our process. Other things we consider at this stage are; what are potential competitors doing, where have they succeeded and where have they failed? Do we need to do research with a sample group or can we just do secondary research (online research, literature reviews, etc)?
Design — Phase 1
Once there’s a good idea of what’s being built an information architecture and user-flows for the product being designed are generated. In cases where the product is huge, a customer journey map may be used. The goals and results we get from these processes are highlighted below;
- An Information Architecture helps us understand how products will be structured. Should all features of a product be accessible before users sign-in to their profiles or should some only be accessible after sign-in? Do some features have less priority so you want to make them accessible lower or deeper in your product? This is what an information architecture helps us understand
- User flows help map out how users move through products to achieve certain goals. If it’s not mapped out at the beginning it can be difficult to ensure that the experience is kept as seamless as possible
- A customer journey map helps us align the goals of the client (Stakeholder) to the goals of the users (target market) of the product. We only do this for huge products because an information architecture and user flows can somewhat achieve this but if the product is huge we may need a customer journey map so that the goals of the client and user are always in plain view.
Design Phase 2
Once all the goals and results above have been achieved and documented we move on to wire-framing. We break products being built down into modules, each module is designed during a sprint. Our design sprints typically last a week, in cases where a product has a wider scope and/or higher complexity than anticipated some sprints may last for 2–3 weeks.
The goal at the end of the sprint is for our designers to have come up with prototyped hi-fi wireframes for that module. This allows us in-house and the client, to test the wireframes as if it were the finished product. Bear in mind that we don’t always have the convenience to sit with our clients while they’re testing, just like you can’t sit with everyone who is going to use your product when it launches. In their minds (clients) what they’re testing is the “real” product just that it’s in black and white and at this point cannot be put online.
Once all parties have tested a module we give the designers feedback and they implement the required changes. We run a feedback and iteration loop for said module until all parties confirm that the module is done. We do this so that we don’t move the product to development then discover a major error or that a feature has been badly designed.
Once all modules have been designed (prototyped hi-fi wireframes) and tested, the designers can then add colour and other brand elements to make the product aesthetically pleasing and beautiful. We test again once we have a full visual design of the product.
Handover
Once the designs have been completed and tested, the designers hands-over to the front-end engineers using Zeplin so that all assets are exportable and all aspects of the designs can be checked; colour codes, dimensions, shadow weights, etc. Zeplin is awesome for handovers
We use Invision for prototyping because it allows designers to create prototypes which can be shared with clients and any other parties that may need to test the product.
The penultimate step of our product design process is for the designers to test once the frontend engineers confirms they have completed a sprint. Similar to our design process, our developers work in sprints. Once a developer confirms that he/she has completed a sprint, the designers test to ensure their designs have been executed in the right way or in some very special cases, even better than designed.
This is done until product development is completed after which, we do a final test of the product before launch.
The final stage, should the client ask us to maintain the product, involves; analytics, feedback and updates but we don’t require the designers of a product to always be available for this stage as it is handled after product delivery.
This sums up our design process. Thanks for sticking by and reading through till this point (even if you just skimmed over). You can apply to our talent pool by clicking on the link below. Looking forward to your applications to join our talent pool.
