Finding a process

I think a lot about process these days. Since we started making stuff for screens, design and development have pretty much been seperate diciplines. I’ve talked about this before and I have been thinking a lot on how to evolve the modern development process.

Most processes I’ve seen have more or less completely seperated “design” from the rest of the development. Now I am a part of the organization for development of frontend stuff at Quinyx and we want to take a different approach. Our team is growing, so our process will likely gradually become more formalized and stale than it has been so far. I have set up a few principles to guide us on our journey.

1. Design is how it works

   We care about design. But we have a holistic view of what design is. The things we often refer to as design – layout, interactions and graphics – are important. But so is performance, reliability, accessability and copy.

   Design is not how it looks on paper, how it is simulated in a prototype or how it is explained in a breif. Design is how it works for the user. This means we avoid using deliverables that might give a false picture of how the product will look and work. We prefer usable prototypes over static mockups, real implementations over Photoshop comps.

2. We want to be agile

   Doing “design” and “development” in seperate steps means it’s hard to be agile. It means you create deliverables and lead times between the different stages. When you work on a short project, that approach might make sense and when you work in an agancy/client setup, there might be business reasons for such way of working.

   But if you are building a complex product that is going to live for a long time and continuously evolve, being able to improve what already exists in an efficient way is really smart.

   This means we want to have a process where the time between an idea and a tested implementation of that idea is really short. If that means skipping steps like detailed wireframes and graphical mockups – so be it. If we like how it works, we can take more time to polish it afterwards. If we don’t, we just try the next idea.

   Our only deliverable is a working product. Anything else that we produce in the process needs to be properly motivated.

3. Good domain understanding is the key to taking the right decisions

   A good understanding our users and the problems that they face is essential in helping us take the right design decisions.

   We work in a pretty complex domain, and dogfooding isn’t really a way to gain real insight for us (even though we do use our own product to some extent). This means we have to spend a good deal of time on making sure we have a shared and correct understanding and vocabulary to describe the domain.

4. Short feedback loops are essential

   Design is about understanding the problem, but it’s also about exploring solutions, about discovery. It’s about trying things to see how they work. We try to make it easy to explore new ideas, to be creative. This echoes both in our choice of tools and in the culture we try to build, where we focus on communication, collaboration and good feedback.

I hope these guidelines will make things a bit easier for us when making decisions about how we do things. We’re pretty happy with it so far.

In a later post, I will share some details on how the process works and on the tools we use.