My Design Process — Deployment & Improving The Overall Process

Posted: 04 Nov 2013 05:30 AM PST

The last couple of weeks I’ve been walking you through my current design process and trying to point out how it’s changed with the shift to responsive design. It starts by defining the problem and planning the solution before moveing into design and development. The last phase is deployment and moving everything to the client’s server. That’s where we’ll pick things up today.

As I mentioned a few times in this series, my process is an ever evolving one and I’d like to also talk a little more about why it evolves and discuss some of the ways I think it can improve from its current state. Here again are the 5 phases my process goes through.

Problem definition
Solution planning
Design
Development
Deployment

Last week I left off at the end of the development phase with a site that was built locally and was ready to be pushed to the client’s server. The process was about to enter the deployment phase.

Deployment

I say push to the server, but quite honestly I don’t have a great deployment process in place at the moment. I’m still using FTP and moving files directly to the server, which inevitably leaves me doing some last minute cowboy coding as change requests come in from the client.

it’s an evolving process, driven most recently by the shift to responsive design

Client changes usually aren’t much at this point, but still it’s not the best way to work. My client makes a request and I sadly modify the live css file knowing all the work I’ve done to set up Sass files grows less and less useful with each change. I’ll probably make the changes locally at first and FTP them to server, but it never seems to take long before I’m editing the live css files. My bad without a doubt and something I’ll address later in this post.

For the most part the site is done once it’s on my client’s server. Depending on the site there might be a few things that need to be implemented that I haven’t done locally, but for the most part the site is done to satisfy me and I’m waiting on my client to give the word the site is done as well.

Some testing will still be needed. I test as I develop, but it’s always good to have another set of eyes test your work. Most things need to be tested again once on the live server anyway. I’ll run through my checklist of things to test, though I’m more concerned at this point with having my client run through the site and catch anything I may have missed.

A few minor change requests might come in. I might walk my client through using WordPress, and of course I’ll be there after launch to handle any problems we encounter. However, I’m also changing gears, thinking about the next project, and working to define the next problem to solve.

Reasons for an Evolving Process

Earlier in this series I briefly mentioned 3 reasons why you should be consistently evolving your design process.

You gain experience as a designer and developer
The industry evolves and does things in significantly different ways
You identify parts of the process that can be made more efficient for you business

Any of the above could lead to a change in how you build websites. I find the first happens naturally and often. You get better at what you do and each part of the process improves. The second happens the least frequently, but when it does it leads to the biggest changes in your process. The last falls somewhere in between. It should happen more frequently than industry changes, but it generally won’t just happen. It requires some conscious effort.

All of the above are driving the current evolution of my design process, though it’s the second reason that’s really been behind the wheel.

Experience — My graphic skills lag my html and css skills. It’s simply quicker for me to create and modify deliverables in code than it is to modify them in Photoshop or similar. This won’t be true for everyone, but for me it is and I’m changing my process to better suit my skills.
Industry — Static comps are not the most effective way to show how a design works, especially a responsive one. It doesn’t mean they can’t be used, but we need to communicate something more than a static picture of a single moment. A working prototype communicates the dynamic nature of a website better. Without question this is driving the changes in my process.
Business — Both reasons above affect this one. Playing to my skills will make me more efficient and moving to prototypes gives client’s a clearer picture of what their site will be. Clients are more involved sooner and the feedback/iteration loop leads to a finished site clients are happy with in less time than before.

Where the Process Can Improve

There are a number of ways my process can be further improved. Let me walk through each of the phases again sharing thoughts for how I might improve them. Some of the phases can stand more improvement than others.

Problem Definition — For the most part this phase works pretty well for me as is. I don’t see it undergoing radical changes, however I can certainly do a better job with it. I can always get better at asking the right questions and listening to responses to those questions.

At times I define the problem through my own lens where I really should define it based on the vision of my clients. Inevitably the site will conform to their vision, but I can probably get to their vision sooner in the process.

Solution Planning — This phase is also working well for me. Improving how I solve design problems is mostly going to be a matter of gaining more experience and understanding of design. As my skills increase and my decision-making improves, this phase will naturally improve with them.

Generally experimenting with how I arrive at some of the more creative decisions and the tools I use to get there are worth exploring here as well.

Design — One thing I would specifically like to do in the design phase is to prepare better style guides/tiles for clients. I’d like to create some standard components that can be quickly modified in order to more consistently present, type, color, and aesthetic options across projects. At the moment I create something new for each project. I could probably add some templates for different grids as well.

I can probably do more with html and Sass modules and partials in order to quickly combine a few parts together, modify them for the specifics of the project, and send the result to clients.

One other thing I can improve is to work more consciously from a mobile first perspective. I do think mobile first, however, I know most of my clients are focused on how their sites look and work on widescreen browsers and so early prototypes tend to be built for widescreen first.

Development — This phase has already seen much improvement due to the changes in the design phase. However difficulties sometimes arise because I hadn’t quite understood how something in the project should work and I wasn’t able to realize it until actually trying to make it work. Improving the previous three phases should help.

My local development server could stand improvement. I run everything through XAMPP (for some reason the people at MAMP don’t want to take my money). I’ve been thinking of getting something like a Mac mini that I could set up as a dedicated development server, perhaps something I can access remotely when I’m away. I think it would also enable me to better mimic the live server environments the sites eventually end up on.

While I’m getting better, I could still improve how I develop initial prototypes so it’s easier to convert them into WordPress themes. My natural choice for class names and ids isn’t always the same as the names WordPress provides and I should get better naming things the WordPress way.

Deployment — This phase needs an entire overhaul. The way I’m doing things with FTP and cowboy coding needs to go. I’m aware of it and simply haven’t yet gotten around to make the changes I need to make.

What I should do is use some kind of version control (probably Git) and push whatever I do locally to a staging server probably on a domain I control. After clients approve the site it can then be pushed to their server.

I have been working a little more with Git this year to better understand and get used to working with it, but I’m not there yet. The biggest difficulty for me is setting up the entire workflow and getting used to it. It seems easy enough conceptually, but I get lost in the details. What I mostly need is to set up a practice site where I can make mistakes while sorting it all out.

Closing Thoughts

When I consider how the whole process is changing, two things jump out at me.

My process continues to move from waterfall to agile. I don’t claim to be an expert on either type of process, but overall my design process is becoming much more iterative with smaller changes being made more often and passed on for client feedback before iterating again.
Each phase of the process is blending more with the ones before and after it. The edges between them are becoming blurred. Even now it’s hard to tell when one phase of the process ends and another begins.

Once again it’s an evolving process, driven most recently by the shift to responsive design. The major change has come about in switching from design comps to prototypes. and involving clients in the process more.

The feedback/iteration loop makes it quicker to get to the finished design, shortens development time, and keeps clients more focussed and involved. It’s ultimately leading to more ownership of the design on their part and generally leaving clients happy with the results.

If you liked this post, consider buying my book Design Fundamentals

The post My Design Process — Deployment & Improving The Overall Process appeared first on Vanseo Design.