The Product Designer’s practice

One of the things that has been hard to miss in the design and UX industry over the last few years is the increased role of the design process. Everything from the popularity of ‘Design Thinking’ to the appearance of ‘The Lean Startup’ and ‘Lean UX’. However, unlike design agencies and consultancies, the Envato design team doesn’t have to sell a process or convince anyone of the value of User Centred Design.

We seek answers to a very simple question, what ‘should’ we build?

Rather than having a fixed, repeatable design process we develop the right skills and build a great toolbox of techniques. We use a set of Design Principles, our experience and cross-functional collaboration to shape our thinking and solutions. We do not focus on deliverables and artefacts, we simply seek answers to a very simple question, what ‘should’ we build?

What should we build?

While the answer is often really simple, the process of answering is often quite complex. As product designers, we need to understand both the business problem (and all the context around it) and the users’ needs. Then through design facilitation with business stakeholders, product managers and developers –backed up by research – we create solutions that magically match the business outcome with the needs of the user. And it’s not just about discovering what we should build, finding out what we shouldn’t build is often just as important.

Finding out what we shouldn’t build is just as important.

We work in a fast paced environment, we don’t always have all the information we need. We have to evaluate the risks alongside product managers and create strategies for testing ideas. Once we have a way forward, we must define the solution in just enough detail to allow the development team to ship a new feature or product to our users.

All about speed

We’ve built a great culture within our design team based on humour and candour. This enables the team to work openly, sharing and discuss the merits and flaws of work-in-progress design work. As a team, we accept that the first version of any design will be rubbish, so we focus on speed at first to get past the bad solutions quickly and move onto the great ones. We aim to get our ideas into the hands of our users as quickly as possible to validate and learn from them, then iterate again and again until we get it right.

Finding the right structure

There are two core approaches to structuring a product design team. An agency style approach where the designers sit and work together on projects, servicing the needs of the development teams and product owners. Or an embedded approach where designers are distributed across the wider team to focus on specific product areas and work closely with development teams, similar to Spotify’s tribes and squads. These embedded designers are then connected together for knowledge sharing and support through guilds.

We use the embedded approach as it allows us to deliver more iteratively and respond to change as and when it happens. It also means our delivery teams are autonomous and cross-functional and not reliant on other teams giving them the freedom to manage their own backlogs and releases. This also means, as designers we are able to take a much longer view of the future roadmap, knowing where what we work on today fits into the work of the future. We also have non-embedded roles which provide support and service to the embedded designers and their teams.

Generalists not specialists

Our designers each have their own product area to focus on, so we need them to cover the full spectrum of UX work, from research and interaction design to information architecture. Therefore we look for what’s become known as the ’T-shaped generalist’ designer with a wide range of skills and an interest in the skills of those around them. Why would we want a single member of the team as the only person that researches users? We need everyone to have the skills to take on a problem and deliver the solution.

Product designers (aka UX Designers)

As a marketplace product, we have two main segments of users, those that buy and those that sell. The design team is split with these user types in mind, we have a buyer team and a seller (or author) team. The designers on each side help the product owner of that side shape and develop the roadmap for the future. But their main role is embedded with the developers in feature teams (referred to as streams).

Envato follows an Agile software delivery process, therefore the designers work on the same sprint goals as the rest of the developers in their stream. They use a range of techniques such as Lean UX and Design Sprints to quickly generate ideas and validate them with users before delivering just enough design, just in time for the developers to work with.

What they deliver depends on the scale of the project, anything from a rough sketch and a conversation, to a higher fidelity prototype in InVision or even a prototype built in code. They are in constant collaboration with the rest of their streams dealing with daily changes in direction and scope. (This is why a sense of humour is important, as we all know how frustrating it can feel.)

UI designers (aka Visual Designers)

We have a team of UI designers who sit outside the development streams. Their main focus is designing for our style guide, which means they work closely with the embedded stream designers to create reusable components and patterns. They apply these styles to our Sketch template which gives our embedded designers the power to quickly mockup screens and flows using existing designs.

UX writing

We use a lot of language and text in our work and we have to get it right, especially when dealing with users whom English is not their first language. We have a UX writer who works closely with our designers to ensure the right tone of voice is applied on everything from headlines and content right down to the micro copy in form labels, help text and error messages.

Let them do what they do best

My role as the Head of UX and Design is not to be the design gatekeeper of our product. It is more about enabling our team of designers to do their best work. Making sure they have the resources, skills, techniques and support needed so they can own the design in their product area and make the right decisions about how and what to design.

The designers are trusted to get the right advice, information and evidence to make the right decisions.

Our streams are self-organising, so between the Product Manager, designer and developers they agree what they want to ship. The designers don’t need to seek approval on a new design, they are trusted to get the right advice, information and evidence to make the right decisions. This freedom is rewarded by braver designs that take more risks and challenge us all to do better work.

Working as a team

The team work really closely together, even though they sit apart, embedded within their streams. They rely on each other for support, opinion, feedback and help. We have a daily stand-up where we share the work going on and discover opportunities to share our knowledge and work together. Every two weeks we retro as a design team to continually improve our practices learning from our failures and celebrating the successes. We also have a regular Brain Trust meeting (borrowed from Creativity Inc.) where we openly critique all the work going on in the design team.

A quick note on research, I’ve not mentioned much about how we conduct and use research as I’ll be covering that in more detail in a future article. However, research is vital in allowing the team to move quickly, therefore we conduct research continuously at a product level rather than for individual projects. We do occasionally conduct quick guerrilla research if we uncover an unknown in our understanding of the users’ needs.

Closing thoughts

There is an ever increasing gap between the work that a product design team do and that of an agency or consultancy. It’s a lot more about responsibility and decision making and less about following a proven process or creating artefacts. We have to ask the right questions to find the right answers and we only realise the value in our work once it’s been shipped into the hands of the customer. But this first iteration is never right, so we iterate, test and learn over and over again until we find our product/market fit.

This article was written by Chris Thelwell and originally appeared on his website.

Chris Thelwell is a Design and UX Leader. He has been a digital product designer in both the UK and Australia for many years, juggling award-winning F1 projects, cool Google Chrome apps and the occasional European football championship. An outcome focused design leader, described by his teams as perfect for leading design, managing teams or changing the world. Chris specialises in disrupting markets, creating innovative new digital products and building high-performing design teams in Agile software delivery environments within large enterprises, startups and agencies. Chris regularly writes for popular design blogs such as Invision, UX Pin, UX Magazine, UX Matters, Sketch App Sources and the True North podcast.