I've been planning and working on this site for the majority of the year. Tonight, I was able to get a lot of the current skin cleaned up, as well as give the site a minor color change to hopefully freshen things up. Next on the list is to get everything caught up to be future friendly , which means mobile. My chosen method to handle mobile for this site is responsive design. Responsive web design is a technique using a combination of fluid grids, flexible images, and media queries as a method of delivering a quality experience to your users no matter how large (or small) their display. Your content is designed to "respond" to the context of the device, thus giving users the content they came for without making them work for it. Though responsive design isn't the best approach for every project, I believe it is perfect for mine.
At first I was hopeful that I could just jump in and convert my existing design, however, that's not really the best strategy. It's not how I would approach this project if it were for a client, so why short change myself? Instead I need to first evaluate my content and goals, my current design, and my users' needs (the hows and whats they'll be reacting to on the site). I want to create a good user experience for everybody; my end users, and myself as an administrator and client. This is a good time to create a workflow.
So here is my responsive design workflow, which is really just a more detailed, focused version of my common workflow. As I redesign the site, I hope to share information stopping at each phase to help demonstrate how this process works.
Discover → Strategy → Text Design → Sketch → Prototype → Design → Test → Discuss until it works.
This first stage is about gathering info, getting to know the client (which this time is me), and researching the work. The main purpose of this phase is to get to know the problem that your design is planning to solve. Find out about the client's business, their competition, and main goals of the project. This for me is also a good time to start discussing tone and emotion; to start to get an idea for what kind of design elements we will be using. There are many questions to answer in this phase, and the involvement will vary from client to client, but the most important question to me here is, "In one sentence, what is the point of this website?"
Strategy is based on the knowledge that is gathered during discovery. This is where I take the answers to those first questions, and start building user stories, information architecture, and content hierarchy. Content strategy, implementation strategy (at least at a rough distance), wire-framing become the main focus in this phase with a goal of establishing a strong understanding of everything from the Discovery phase. This is also a great time to double back and make sure nothing is missing before you start putting in time and effort toward the design.
3. Text design
This is one of the most important stages in the whole process, and yet it's probably also one of the most underrated steps. This is when I really start my content strategy. I create a design that is only text based. Content is the reason why people come to the website in the first place. I like to do this with HTML without styles, so I can see how the content appears plainly. This allows me to focus on the content and its hierarchy without any emotional distractions.
I will admit not all project can afford for this step (though they should!), as not all project have a content strategy. In a perfect golden design world, you will always have content before you design, but what I have experienced is more often than not, clients focus on content changes last, or tend to want to keep that info closer to the chest. Having content up front, ultimately will lead to better success of the design. After all, the design is merely there to support the content, not drown it out.
Sketching ideas is usually something I do first, and really all the time throughout the design process. By spending a short time sketching you can save yourself hours on a .psd file or writing code. This step allows you to make quick decisions, with no risk of loss. I prefer drawing on paper, but also have been known to mock-up in Photoshop first. I always end up with my final designs in Photoshop, measured to the pixel.
Prototyping early in HTML/CSS is extremely helpful. It's one of the only ways to truly see how the layout will respond to different viewport sizes or (e.g. you can make sure that you can actually click those tiny links in your wireframe). This also allows you to see the site much sooner and react earlier to any problems in the design.
Again, this is another step that sometimes can get skipped over, but when it comes to responsive design, I feel it's really important to work this in. If I'm working on a non-responsive site, I can let me experience guide me in how the site will work, without having to worry too much. Prototyping can be more than just helpful with responsive design, it can also aid in ensuring you have created a good basic user experience. This also allows clients to focus on the content flow, and UX without getting distracted by the emotional design elements (colors, images, typography).
6. Visual Design
Feels like a lot has happened before we got here, right? This is the fun part! This step goes hand in hand with sketching, and with more experience, can often take the place of prototyping. I create a Photoshop mock-up of the final design, and based on the needs of the project, will comp out each significant page or experience. This is the part where we get to use all the info we gathered in the discovery and planning phase and add colors, typography, etc. to our design.
Introducing testing early on will save you from possible headaches in the future. It's challenging to build responsive sites, even more so without testing them on a number of actual devices, or reliable simulators. Testing should also include user experience testing; I try to put myself in the perspective of each type of users for the site, and confirm that their needs are being met. Don't even get me started about browser testing...
Discuss with the client or even coworkers and peers during all iterations. This isn't always possible, but when you can do it, you have a much stronger chance of the client understanding your solution, and getting approval. I look for approval at wireframe, prototype (when applicable), then design, before I even start to code the final product. Approval at each step ensures that big things don't derail the project, and keeps expectations met. This also helps me stay agile if there are any major scope changes in the project. It's tempting to wait and reveal the "final design," but getting feedback early and often helps save time, and save yourself from having to rework any mistakes or oversights.
9. Wash, Rinse, Repeat
Not every attempt is perfect, and as you can probably tell, this workflow is meant to be circular. If something fails between Text Design and Prototype, go back and repeat until it works. There is no perfect workflow and many teams work differently. Often, I'm not in control of the workflow chosen for the team; however I still take responsibility for making sure I follow my own workflow as much as possible. Check off what you can along the way, and take notes on what works best so you can keep perfecting your trade. Trust me, in the long run it makes life easier!