When you choose a digital agency for your project, you also make a choice between different design philosophies. Here's ours in a nutshell.
When you're choosing an agency to build your digital service, you're essentially making a choice between different design philosophies. This article offers a quick overview of how we approach projects – and how we've come to these principles after 10 years in the business.
Designing, building and releasing a digital product can be a daunting task, with many potential risks along the way. So what, from our point of view, is the best way to approach these projects?
Having completed over 150 projects during the last ten years, we're surer than ever of the fact that each one is different, and requires a somewhat unique treatment. However, that does not mean that there can't be general guidelines for how to make your service the most successful version of itself.
In this article, we go through a series of phases we feel apply to just about any digital project, regardless of size and details of the service itself.
Software projects are no small undertakings. Thus, the first and most important goal is to make sure that the project is worthwhile in the first place.
Getting to know your business and its goals is vital, as is understanding what your users actually think and need. Meticulous research and brainstorming is the name of the game here. What is the value proposition of the product we're about to build? What are its competitors in the market? What need does it try to solve? Are the hypotheses we have about the potential users actually correct? The main goal of this phase is to create a solid and tested value proposition.
It is to be noted that the Discovery sprint can also be technical in nature. Considerations about which technology would be the right fit for the project are not always obvious – the Discovery phase often includes preliminary tech tests to make sure we're making the right choices.
Seamless interplay between UX Designers and Developers is essential; we want the features to be both technically sound and user-friendly.
A typical length of a Discovery sprint is 160 working hours. In some cases, this first phase of the project could also be its last. And that's ok – sometimes ideas need to be dropped altogether, sometimes they need more time to mature or turn into something else entirely. But that's part of the reason why the discovery phase is there to begin with; it's absolutely essential to figure this stuff out before you start burning money on implementation.
After the foundations of the project have been created, it is time for the first implementation sprint, usually around 160-200 hours in length.
Here, the seamless interplay between UX Designers and Developers is the key; we want the features to be both technically sound and user-friendly.You don't want to jump straight into technical implementation, either. Creating the design and testing even before the technical implementation gives us the chance to see if there's something wrong with the fundamental design choices. At this point, it is much quicker to make even bigger changes if need be.
Depending on the what we're building, the goal is usually to have an MVP (minimum viable product) ready to be shipped after a couple of implementation sprints. Most often, the best way to know what to do next is to put the service out there, execute your marketing strategy's launch phase (you do have a viable marketing strategy, don't you?) and closely follow the key events in analytics.
This, especially paired with focus group interviews, usually gives us a pretty good idea about which aspects of our user journey need further development. This is also the beauty of MVPs; in conjunction with analytics and research, it lets us build a strong foundation for the core features first.
For most digital products, the development continues for as long as they exist. MVP is usually simply the first step in a long series of updates, new features etc. However, the basic loop of the sprints remains the same: research/plan, design, build, test, repeat.
The basic loop of the sprints remains the same: research/plan, design, build, test, repeat.
Rarely, there are services that for some reason or another do not require much further development. If this is the case, the project status can be switched to upkeep mode. This is where only bug fixes and basic upkeep is performed, usually on a monthly basis. For most digital services, however, "build it and leave it be" is not a reasonable strategy.
Before each sprint, we plan the features to be implemented in the next sprint. Features lead to tasks, which are prioritised, and tasks lead to goals for the sprint. Tasks, priorities, and goals together form a sprint plan, which is the guideline for the developers and designers to implement during the sprint.Additionally, weekly meetings are used to follow up on the sprint progress and to actively communicate and solve potential challenges in implementation.
After each sprint, a sprint retro is held with the full team to learn about the successes and challenges faced during the sprint. Sprint retros help us to make better sprint plans and enhance us work better independently and as a team.
So, what is the guiding principle in our approach to building digital products?Simply put: careful design makes the work more efficient.
We take pride in having versatile and incredibly talented developers in our ranks. However, they do not have access to crystal balls. Doing guesswork by coding something and then backtracking because it turned out not to be the best decision is always much more expensive than building concepts and testing them with design tools. While this approach does not eradicate the possibility of missteps in technical implementation, greatly reducing them has a dramatic effect on how much can be achieved in any given timeframe.
What is the guiding principle in our approach? Careful design makes the work more efficient.
This is essentially how we offer the best possible value for the time we spend on a project during each sprint. More progress in a shorter time without sacrificing one iota of quality. Or, in layman's terms: more bang for your buck.
Of course, one article cannot cover every aspect of our approach to building digital products. If you're interested in reading more about the way we manage projects, approach agile development or decide what technologies to work with, check out the following blog posts:
