Back-end development and design
Editor’s note: This post pre-dates the merger of Big Nerd Ranch and Highgroove Studios. Big Nerd Ranch now offers end-to-end solutions that include design.
At Highgroove, we specialize in back-end development, and we’re really good at it. We are not, however, designers. This is probably for the best; I, for one, have artistic talents that stop at drawing various stick figures.
Why doesn’t Highgroove do design?
Although we believe that design is essential to making a web application successful, we’re a team of experts focusing on killer back-end development.
We’re happy to work with anyone outside of Highgroove on your project, and if you need a designer, we’ll be happy to refer you to several.
The process for design implementation needs to be agreed upon by all parties before work begins. Are the designers going to be directly modifying the code or providing the developer with HTML? Will they be providing multiple versions or just a final version? There are a lot more questions here, but your developer knows them and will work out details with the designer.
Then, once we’re building the site and adding features you request that are not included in the design, or moving things around, we’ll need some more of the designer’s time. We highly recommend that you budget to spend as much on this “extra” time as you spent on the initial design implementation which will typically be in the form of an hourly retainer. While Highgroove can do some of these things, you definitely want us working on feature development instead of spending hours figuring out an Internet Explorer specific visual bug that the designers could fix in a few minutes.
Understanding the relationship between design and coding
This doesn’t mean that we don’t understand the value of a good design—and we certainly believe in the power of good work. It just means that we work with outside designers, rather than staffing our won.
In fact, I get to work on my design skills with my personal projects. I enjoy thinking about design and how the user will interact with whatever I’m making. Even before I dive into the code, I usually spend some time trying to come with a UI and basic design. I even secretly kind of enjoy building up the layout with HTML and CSS (but of course I don’t enjoy the parts that deal with browser compatibility).
Thinking about design changes how you develop
Playing around with UI and design has shaped the way I develop. I’ve tried to make my code more modular and simpler so that it’s easier to implement on the front end, especially when I’m able to pinpoint specific areas that contain similar functionality.
When I first started learning Rails, I was working on a bunch of personal projects and doing my own design for all of them. Doing so forced me to examine and plan out how I was going to code it, because it made me identify different models that I’d need to create, which controllers I would need to aggregate actions, and what actions and views I would need in order for the users to interact with the models.
Whenever I have an idea for a web app, one of the first things I’ll do is open up Photoshop and spend a few hours mocking up a design, colors and all. Working this way forces me to think:
Is this something I would use?
Is this UI too complicated?
What are the specific features that people are going to use?
What are some potential code-related problems that could arise?
In fact, I did this just the other week. After working through a design, I figured out that the idea was a little redundant compared to apps that are currently on the market, so I’m working to change its purpose.