I just want to see how the pros do it. Could you guys explain your design process and workflow from initial brief to handing it off. Also could you detail how long (on average) it takes to design each website. I'm self taught and have only been learning this for a year so anything you say will be super helpful. Thanks guys.
Everything I do starts with a story.
A story is basically a document that tells me the who/what/when/where of what I'm about to create. Preferably this story is in gherkin format.
A story is handed off by a product owner to me. I read it and while I read it I'm making sure it's accurate. Does the story consider most scenarios? Are the requirements enough? Does it make sense? I ask questions and do some research.
Then between the product owner, the lead developer, my director and I, we all will groom the story, submit feedback, and iterate on it. Once the story has been given the stamp of approval by all parties we're ready to move forward.
On top of the notes I take during meetings, I sketch important things to remember, some ideas about architecture and layout for this product. During this time I also do further research to validate some ideas and to get a sense of direction.
After sketching I'll start wire framing the site flow from a low-fi view. I outline pages, interstitials, call-to-actions, etc. Sometimes the site flow for devices may be slightly different or majorly depending on what you're building so I consider alternate flows for different devices.
I share the site flow and get any feedback and then I move forward with hi-fi wireframes. When I wireframe I focus on one view at a time across all devices at a time. For example, when I wireframe a registration page I will work on desktop, tablet, and mobile at the same time for that particular view.
I be sure to annotate the page, pointing out features, actions, interstitials, statuses, etc. I try to add as much detail as possible while being sure to show what happens when you click/tap on something.
I make my first pass at all the pages and then share it with the team for feedback. Sometimes I'll share what I'm working on early so I don't get too deep into the wrong hole or to get another perspective. I may prototype some interactions for better understanding as well.
After a few (or many) rounds of iterations and the wireframes are approved we move on to...
In a perfect world there exists a style guide for everything you work on, unfortunately that's not always the case. When I design I try to stick to some basic rules and be consistent as possible, It's sort of like creating a style guide on-the-fly.
I make sure to note these rules in some documentation.
I design the visuals much like I do the wireframes, one view on desktop, tablet, mobile shown side-by-side.
Sometimes you don't always have to design all the pages, in certain cases focusing on the most complex page that has a wide range of UI elements or pages with unique features is good enough. If you've established the rules for how forms are treated you shouldn't have to do another page that has a ton of forms on it, the rules you've established can apply to that.
The sooner a style guide is established the better. You can spend more time on how it works and less on how it looks. Once I complete the visual portion I hand it off to the team for feedback (and again, you can collect feedback sooner, quicker, more often as needed) and make changes as necessary.
Typically a meeting is scheduled with the developer for feedback or questions.
Once the product has been built, a quick meeting with the developer is scheduled to go over what he's made for any feedback.
If it looks good and works well, ship it and then test it. Iterate and update as needed, see how users respond.
I think about my process and I'd like to incorporate more research and prototyping in it and some more development on my part. I'd like to merge the gap between design and code as much as possible.
Interesting post. When you say Gherkin format are you talking about structuring the user story as "We are this.../Who wants to do this.../Because this..."? Short simple breakdown of the logic?
Yes, exactly that.
Scenario: User adds item to cart
- Given I'm a logged-in User
- When I go to the Item page
- And I click "Add item to cart"
- Then the quantity of items in my cart should go up
- And my subtotal should increment
- And the warehouse inventory should decrement
The style guide stuff is really important. I did a talk last night on it and why designers should create them to benefit others designers and the developers. It's amazing how without them, multiple designs can become so inconsistent it's impossible for developers to know what colours to use, what certain spacing should be etc.
It's a huge issue. It's also incredibly difficult to establish a style guide with a product that's existed for many years without the use of one. I think some people believe that a style guide is owned and maintained by the designer, but really everyone should own it and contribute to it. It's impossible for me to create an effective style guide that has any huge impact without developers buying into it too.
Here's how we do it for medium to large projects, but keep in mind the process varies per client and per project. We might skip steps or add more in depending on how well we know the client and what's needed. I've also probably missed some interim steps in here.
High Level Requirements
Usually a client approaches us with a basic idea of what they want to do (e.g.: sell widgets online). In our first meeting with them, we try to flesh the idea out with them a bit more to cover some bases they probably haven't though of yet.
The aim for us in this meeting is to scope the higher level problem they're trying to solve (e.g.: they need a website to sell widgets to their existing customers and bring in new customers) and start giving them an idea of how we'd approach the project.
Once we've understood the problem, we go back to our team of designers and developers and explain it internally. We throw around ideas, try to identify any obvious issues in the approach that may come up (e.g.: their current customers buy widgets via fax)... essentially we try to make sure we really understand the problem.
From there we scope out the job. We make a bunch of basic assumptions, and then decide what research we need to do (e.g.: find out if the fax customers are willing to buy online) to confirm them. We also work out our internal plan for the job - how long will it take, who will work on it, how the hell are we going to fit it into our already packed schedule etc.
At this point, we have enough information to provide a proposal and quote to the client. Occasionally we'll submit some really basic wireframes with the proposal so that they better understand our ideas - depends on the project/client.
Assuming the quote's approved, we get on with production.
Research, Sketching, Wireframes
The assumptions we make are based on experience and best practice etc., but we try to confirm them with research (e.g.: the current customers will buy online but they're worried about security).
At this point the lead designer for the project starts working out an overall design structure and look and feel that meets the brief. I personally always start sketching on paper - I find it much, much easier to get ideas down on paper before moving to anything on a computer.
Once the basic ideas are down, I transform them into wireframes for the key screens, sometimes showing default states and then maybe some of the key interaction states. Everything is still rough at this point, but explains the overall idea of how we're approaching the problem.
We run through wireframes internally once they're "complete" to explain the design approach to the development team in case there are any issues with the overall ideas. We then usually try to present wireframes to the client within the first 2 weeks of production to make sure we're on the same page as the client.
Note: During this phase our developers are usually starting on database designs and basic setup.
We usually take the key wireframes we made and use those as a starting point for design concepts. The idea of the concepts is not to present a final, polished product. It's to give the client a (very good, but not complete) overall view of how we see the project coming together.
Personally, I seem to need about 3-4 major revisions (i.e.: different design directions) before I get the right overall idea down, and from there I work out the design for key screens and major interaction states.
Again we run through everything with the team internally before we show anything to the client - it's good for feedback but also for weeding out any potential issues.
We may have lots of internal ideas/revisions, but we only present one set of design concepts - one definitive, overall concept for how the site should look and feel. We try to always present it to the client in person, explaining the key decisions we made along the way, and we always explain that these aren't final ideas - if we think something will work better in a different way once it's been developed and is working, we might throw this version away and use that instead.
The client almost always has feedback on the design at this point, and depending on what it is we will either revise the concepts, or incorporate the feedback during development.
Though this is technically a separate phase of our process, the design phase never ends. We take the design and turn it into an actual living breathing product!
I say the process never ends because there are so many design decisions that are made along the way - from the minute the development starts, there are dozens of tiny decisions that need to be made.
We try out a lot of ideas during development, things that might change part of the the design in a fundamental way. They're usually to do with how the interaction design works - if the designed concept works well, that's fine... great! But if we find that it's not quite right, we have no qualms throwing the concept away and redesigning it from scratch so it's better.
As development progresses, we keep the client updated throughout - especially explaining why some parts might have been drastically changed - and as we get closer to completion, we do a lot more of a hands-on handover/training with the client to get them ready to manage it themselves.
Once we've shipped, we generally work with the client to assess how it's going, do some more research based on how people are using the site, and often plan out later phases to work on... rinse and repeat!
Idk if i'm a pro, but i've been doing web design for almost 5 years and work as a Front End Designer.
Briefly, I find it easiest to start with what the project is, who it's for, what needs to be there.
I'll usually make a list of pages I feel should be on the site, and from there break each page down into what content should be on it.
After some trial and error, i'll sketch out with pen/pencil a few rough mocks of each page until i'm happy with placement.
Then depending on what my client and I agreed on, i'll deliver some Hi-Fi mocks (designed in Photoshop, usually also when I mess with color schemes/typefaces), and we'll go over them together.
Once they're happy, i'll code it up, generally without any bells and whistles at first, jsut so they can see how it feels to interact with it.
if everything is still a go, i'll hunker down and flesh out the rest
Might have missed a step or two in there but generally I find this works for my work style, and that's what it really comes down to, What works best for you. Hope that helped a bit! Interested to hear what others have to say.
Unfortunately I don't have the time right now to write out my whole workflow but I'll try and come back tomorrow.
In the meantime, I ran a full service eCommerce agency (just me) for 3 years and have recently formalised my frontend dev boilerplate as a git repo and decided to make it public.
Might be worth checking out as it's where I always begin when I first start cutting code.