Design @ Prezi — Part 1
How do we design
Intro
We’d like to start off a series of posts about how we (designers) work at Prezi with some history, process basics and then follow up with solid details and experience about our job. Post by post each month we will uncover parts of our process and write about our team’s inner workings.
Some history
The decorators
There was a time when most of the software companies had some “designers” operating as an in-house agency providing assets for development (There still are some). It was kind of the same for us too — They need a button? You send them a png. (At least it was easy to explain to our moms what we were doing. Drawing buttons.)
The owners
As the importance of design and user experience reached higher levels, we chose our path to be the problem solvers. We wanted to own it. Working in a silo is a very comfortable thing. Getting input in the form of a problem and providing solution proposals (sometimes only one). There is little or no transparency of the design process and the end result will not necessarily remind you to the proposal, but that’s the price.
The facilitators
I’m sure you’re sick of hearing about the Design Thinking method and its process, but you know, it’s just the way things work out for us too. We realised we can only make a solution really work if everyone understands the problem and is involved throughout the whole process. We wanted to introduce an Open Design Culture where all the people in our cross functional teams have their hands on deck.
Our design process
We had to shape our process to our needs, but it’s basically following the guidelines of the IDEO based principles of Empathize — Define — Ideate — Prototype — Test.
- Naturally, we’d like to understand and empathize with the people we design for. To do that, we partner with our UX Researcher and Data Analyst to make sure we are on the same page as our users.
- Together we frame the problem, formulate hypotheses from assumptions with the whole team.
- Get a lot of ideas on the table.
- From those, we condense some concepts that are worth a closer look and make prototypes to learn about their strengths and weaknesses.
- We iterate until we get to a couple of solutions we believe in, and add that little extra, the soul.
- We build, measure, and in the end we’ll see if our solution works in production or we should go back a couple of steps.
I have to say, going back doesn’t happen often at this point if the process was well done. This gives us the responsibility to make sure it is.
We understand we can make the best solutions if we work with other people.
We can pick their brains and use their strengths to build on it together. This also gives us increased visibility and a much higher level of trust, which also makes the process easier.
We work in co-located, cross functional teams where each team has its own designer, researcher, analyst, manager, and mighty developers. We are now a team of 12 designers, 10 researchers and 6 data analysts. We often work together in a place in the Budapest office called the “Creative Space” where we conduct our design studio and critique sessions as well as community events like retrospectives.
Not everything is perfect
All the above is of course the ideal process and setup we work with. The hard truth is that sometimes it does not happen like this.
Some product teams lack designers, the process is hacked by time pressure or a solution we get hooked on. Still, we always try to get the most out of what we have and this is a learning process.
Upcoming
More details about parts of the process and day to day work from the designers perspective at Prezi.
Originally published at www.linkedin.com.
