--- title: Design Driven Development teaser: The benefits of designing, then developing, rather than vice-versa. tags: playbook,design author: Fred Yates published_on: 2011-01-05 --- Most of my thoughts about design spawn from asking myself what makes a project successful. Well, what does? Most will agree that good design does. This is not speaking exclusively about the graphic design or implying that everything rests solely upon the shoulders of the Designer. **Everyone is a designer. Design is a fundamental part of everything.** Keep this philosophy in mind for the entirety of the project. ## How we guide projects thoughtbot has always been known primarily for its Rails expertise and as such the projects have been driven majorly by the development, headed by a Lead Developer. Over the last year or so, with the addition of new designers to the team, we were able to focus much more on design. We've started with design first, as we should, and this has been quite successful. The general practice was to do our research, form our wireframes, and move onto the visual design. The problem is, once we got past the initial design steps our process would splinter a little. Design would still be important and never forgotten but a detachment formed between the design and the development. Now, we want to fix this. We need to make sure that whatever we're working on is the most beneficial thing to the end user. We work off user stories and shouldn't pick ones to work on because they're easy or need to get done eventually. The user stories should be prioritized with good design in mind. We must stay vigilant in creating the best possible product for the target audience. A great way to accomplish this is to keep the design of all things at the forefront of our thought processes. Keeping a project driven by design will help this happen. ## The improved way As of late we're beginning to drive projects with design from start to finish. As I hinted at already, this does not mean a project should revolve around the graphic design or visual aspects. This means the design of **everything** should be well thought out. From things as simple as structuring the meetings well, to things as complex as building the code properly, to things as crucial as wireframing the flow of the app. Design should be at the forefront of our thoughts in every step of the building process. ## Things to help improve We've had great success with a few things lately. None of them are new ideas but sometimes we just forget about them. They are all things that both a designer and/or a developer can accomplish. ### For early prototypes, faster and simpler is better than slower and more polished Recently on one of our projects we wanted to test out a proposed flow for a new app. In a day or two we were able to bust out some very unsexy but very understandable HTML wireframes. They were clickable, buttons did what you expected them too, and you could navigate between pages. The app didn't have any real functionality but it helped both the client and us easily identify trouble spots and conversely figure out what was working best. This was immensely helpful and saved quite a bit of time in the long run. ### User test early, refine, user test again On another recent project we wanted to get something in front of people as early as possible. Similar to the wireframes in the last section, the app did not work. It was a little more polished but really just a pretty wireframe. The difference between this and the previous method was the people running through the app were not part of the team. Even having a few people unfamiliar with the app click through and share immediate thoughts let us rapidly modify the app and only a week later, test again. Over the course of 5 weeks we did this 3 times. The client is pleased (and enjoyed listening to the feedback) and the app is undoubtedly in better shape than it would have been if we waited longer to user test. ### Keeping designers, developers, and clients connected One of the biggest problems, in my opinion, is having the design and development relationship splinter as the project grows, both roles will just work on what they feel is best without consulting one another. There are a few things you can do to help avoid this. The biggest aid, in my opinion, is designers, developers, and clients work physically close to each other. Members of teams at thoughtbot all sit together, and we've undeniably had our best results when the client was able to work with us in person. We can easily verbally communicate at a moments notice. We've found that asking user and goal related questions, discussing as a team, and coming up with the best solutions really helps to keep us on track and work as one unit. Questions like: * Who are the users? * What are the primary goals for the users to accomplish? * What things need to happen in order for the users to perform these actions? ## Try it out To facilitate these ideas, whoever is best fitted and most comfortable to fill a role that focuses on designing for the user experience should be the project lead. This can be a designer or a developer. **Everyone is a designer.** Everyone helps the design process. So, if you haven't tried this process yet, give it a shot on your next project. Embrace well thought out design in all aspects of your project, and see if you don't feel better about the end result.