Where the design community meets.
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
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.
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.