Take a look inside Design at The App Business
In this post, we are going to unpack our process for designing meaningful software products at The App Business. And if at any point it looks or sounds familiar, then it is probably because you are doing it right.
A reflection of our industry, The App Business has grown rapidly over the last number of years.
While many agencies undergoing the same might look to match this growth by scaling the headcount quickly, in the design team, we have instead focussed on how to be smarter and more effective at solving design problems with the team we have. By concentrating on preserving and evolving our working culture over any hierarchy or structure, we have kept the team relatively lightweight, only incrementally increasing the headcount when we have come across the right people, with the right skills and fit for the team — not merely hiring because we feel we have to.
The growth of our team, and the evolution of our design process, has been — and continues to be — a collaborative effort with everyone adhering to the same principles. This includes leaving egos at the door (a tough one for designers), and always making time to meet up every week to reflect on our work and help each deliver meaningful products.
This post looks at our ever evolving process, which whilst unique to us, when you get right down to it is really about good practise and putting the people who use the products we create right at the centre of it.
Culture and principles over rigid structure
Here at TAB our projects are very diverse, and correspondingly, our design team covers a number of discrete skill sets. These include: Visual Language and Brand (UI), Motion Design, Interaction Design, Information Architecture, Strategy, Research, Content Design and Prototyping.
Each skill set is comprised of a range of activities and resulting outputs. Visual Language and brand (those typically associated with designers) can include the iteration and creation of interface elements (UI), style guides, mood boards, brand guidelines, photography and other visual assets. Research, on the other hand, would require user and stakeholder interviews, usability testing, personas, competitor analysis, surveys and other appropriate means of capturing data to inform the design process.
Dissecting design at TAB this way allows us to map out the capabilities and strengths of each of our designers on the team. It means we can better place a designer on a given project, matching skill sets to requirements. We can also see much more clearly where we need to develop capabilities — through training, development or hiring.
What is the team’s approach to design?
When it comes to practicing design, it’s clear that everyone has their own creative process and way of realising a solution for a product or service. If you were to just do a quick Google Search you can see the plethora of ways different designers work, in different contexts. It might look noisy and disparate, but ultimately, we believe such diversity of process is testimony to the fact that there is no single right way. However, that’s not to say that the best design processes don’t have a lot in common — the good ones certainly do and are underpinned by a logical, systematic approach.
Ours is loosely modelled on the Google Ventures 5 day Design Sprint. Their aim is to answer ‘critical business questions through design, prototyping, and testing ideas with customers’. We like to work to a similar sprint cadence as GV, but we cycle through the process a number of times with key checkpoints and reviews before delivering any end product.
In terms of how we ‘do’ design at TAB, first we look to uncover what people are trying to do, and how they currently do it. Sounds simple, but we often see products that misunderstand this. Initially, we build up this insight through a phase (or phases) of research, and this in turn generates a set of initial ideas we can begin to iterate.
This iteration can take many forms, such as ideation sessions with the client, or stakeholders using an Outcome Driven Innovation framework, similar to the MAT model explained in a post over on The App Business blog. Whatever tool or approach is used, the key aim is to ensure we are really meeting the needs and desired outcomes of the intended users.
How do you know your design works?
Collaboratively, we beat stuff up together until we can objectively pick the best idea (or a collection of ideas). Then, we make something… and at TAB, this is the bit we really love: the point when it gets really messy, and really exciting.
Why? Because releasing design into the wild produces results you can’t possibly predict. Once we have something we can put into people’s hands, we can watch and listen to how people use it, then we can begin to iterate and tweak designs based on their responses. As designers, we often learn surprising new things through this process. This in turn drives continuous improvement in our designs, and in our method.
Even the crudest of prototypes — and here I’m thinking of that sketch you drew on the back of an envelope — can deliver an amazing amount of insight and guidance on where we should steer a product. We take a closer look at how we use prototyping in this post.
The feedback we get at this prototyping stage may end up sending us all the way back to the start of the process. And that’s ok — as designers, we’re here to deliver something of value, after all, and if it doesn’t then we need to rethink. We may also have to revisit or generate more ideas, but whatever the output is, we’ll keep iterating and learning until we get to a level of confidence about our design approach.
What happens next?
With a validated prototype, we can then begin to take our findings into a more rigorous build stage with our engineering team. We continue to fiddle, prod and pull at everything — but only after having made some very practical decisions about the product upfront.
Throughout our design process, we are — like all teams here at TAB — working Agile. That means balancing the Agile Principles against the objectives of the project. So, we know from the outset that changes will occur, pivoting or halting the project as the team needs to adapt.
All the design artefacts we generate are kept as lightweight as possible — just enough to help us progress through. This helps to mitigate waste and avoid the tedious task of maintaining mountains of paperwork and documentation.
Collaboration is also a fundamental aspect for how we work at TAB. Everyone is client-facing, and everyone within a product team — including not only our Designers but also our Engineers, Architecture Owners, Scrum Masters, Strategists, Product Owners, Testers… all of these experts are required to input into the process.
We must also not forget the most important contributor of all — the people who will use the product. We truly believe that a product or service experience is everyone’s responsibility.
We must also not forget the most important contributor of all — the people who will use the product.
OK, let’s wrap it up
Now, if we were to be like everyone else and diagrammatically present our process, it could be simplified into 5 steps:
But as my post suggests, it’s not an entirely linear process: it will continuously loop as we iterate for as long as necessary — and no more. This allows us to arrive at the best possible solution. The reality is that the entire project needs to be in a perpetual loop of learning, creating and building in order to be effective. Even when a product is ‘live’, the design process isn’t complete.
When it gets out into the real world with people touching, smudging, and feeding back on what we create, things start to get even more interesting. In fact, I give it a few weeks before this post is revisited, updated and tweaked based on feedback. So if you have any or want to know more detail of the process then leave a comment. You can also tweet me directly @imcconchie.
This post orginally appeared on The App Business blog.
