It's a bit of trial and error depending on the project. Sometimes I skip some steps for obvious reasons. I'll share them here hoping this process will improve / be adapted by others.

1. I always try to answer this question: my site/app needs to ___. And I always keep in mind the concept of Maja - depth, utility, beauty.
2. Sometimes this helps to create a brief - http://www.black.design/
3. Design focus research (usability testing, ethnographic studies).
4. Brainstorm - What is the problem we want to solve? What is the solution? (find the right solution and features)
5. Prioritise ideas (MVP), focus on only one feature and 2 sub features max, that are necessary to make your core product work.
6. I create Personas, proto-personas, scenarios storyboards - interview potential users, surveys, talk with potential users. (who they are and how the product will fit in their live) - goals answers the WHY question, and not the WHAT question.
7. Then I create user stories using the person at #6. I don't go too much into detail, something along the lines of: As a [… user persona ...] I want to [… accomplish something …] so that [… some benefit happens …]. Example: As a parent, I want to sign in so that I can access my child’s grades and related info.
8. Create User Flow Chart / App Flow Diagram / Sitemap (this looks messy :P ).
9. Content (interpret and communicate the content - the design must reflect the spirit of the content) - unfortunately many times is auto-filled in Sketch and not many customers understand the need to provide it. So basically I am left with using good defaults and hoping for the best. :)
10. Define grid (if used) - fixed / responsive grid, columns and gutters
11. Define what the viewport is for specific screen sizes, so that you can create a composition taking that into consideration. (for websites it's different breakpoints, for example see this http://dev.vuzum.com/breakpoints/) For apps it's the 1x, 2x, 3x mantra. I'll write a good post about it sometimes soon. The idea is to start at 375x667 as your 1x.
12. Mockups (drawn).
13. Wireframes (using sketch real quick, or balsamiq) - Will this compliment and reinforce my site's purpose? Is this really needed or am I just filling space? Will this be distracting from my site's purpose?) - filter, filter, filter - until there’s nothing that can be removed (get out of the user’s way, users come to the site for the content.
14. Create Color Palettes (ideas: using photos/paintings of specific context - like space for science book, check contrast between colors with different tools afterwards)
15. Create Style Guide (a reference sketch file with multiple instances of typography and UI elements used on the website/app)
16. If needed, I sometimes split the Style Guide from the elements and create a separate UI Kit.
17. Create Pages (usually for each screen category, or page in a website)
18. Create Artboards per pages (basically, each page or screen has more states, these are done as Artboards).
19. Set proper grid and layouts per Artboard.
20. Create Symbols and shared styles for layers. I'm using Sketch and you should too.
21. Design interface (magic)
22. Organise layers. MANDATORY! :)
23. Responsiveness if web, otherwise simply export in 1x, 2x, 3x and take care of the fine details.
24. Sometimes I create a prototype in Invision or Marvel if I work on a project for a client. Otherwise I have my user flow chart that is enough for the dev team.
25. Interactions mostly to get approval from client before we code without a direction and to explain the developer how it must FEEL (Origami, FramerJS only if Origami cannot do it)
26. Presentation Layout - basically the design goes in a mobile or a chrome frame for presentation to the client.
27. Perform usability tests. Go back to point 1 if needed depending on the results.
28. Export Assets. This is important. Your developers should not open Photoshop or Sketch. And they should not experiment with values in CSS. You must be able to give them the assets correctly exported, including preferably a zip exported with https://github.com/tudou527/marketch, and the measurements on an alternate screen using https://github.com/utom/sketch-measure for distances and sizes. And a folder with the assets exported properly so they can simply place them in, and when needed CSS styles copy / pasted in a separate document for gradients and stuff like this. There's also Inspect by Invision and Zeplin, but these are not free. Don't be an asshole, do this right. :-)
29. Be available during development to answer questions, alter assets as needed.
30. Be there to QA the deliverables (not just UI but also UX).

Next time a client tells you design is easy, send them a link here. If you can remove any of these steps and not affect the quality of the product, you tell me which step you would remove and I'll tell you what will change.

I'm old, so I sketch out ideas on paper sometimes. If it's a project for myself, I'll just jump into a text editor and start coding. No frameworks or any fancy stuff, just text on a page. If it's for someone else, the process usually starts with a few mockups in Photoshop before any coding is started.

My design approach begins first by burning sage and walking with the smoldering fire stick to every corner of the room with my head solemnly bowed down.

Once the room begins to fill with smoke and people begin to choke, everyone is asked to stand as the leader of the organization proceeds to bang a gong to commence the design process.

We then simulate a thunder and lightening storm with sound samples. The lights are flickered on and off, and everyone is given a kite on a stick with a keychain attached to the bottom and splashed with buckets of water.

Our participants then experience a mild shock that emits from the kite stick to simulate what it feels like to innovate.

Feel the innovation... Praise it!

A foosball rod is spun, the leader of the session snaps a bumper pool cue over his knee, and that gets things going.

Everyone is then seated in bean bag chairs, Rubic’s cubes, nerf guns and other objects of creative irony are placed in front of the subjects. The hands to the side, palms to the sky and ceremonial goat bones are passed to awaken the third eye chakra.

A basket is then passed and all participants are asked to place their wallets in the basket and they’re reminded that the entire place is under surveillance and the session is being recorded.

The subjects are then asked to put on blind folds...

--

Ok, for real.

There is some really good stuff here others have mentioned in terms of tactics and organization.

In terms of technical execution, the design part, I run similar to how others here have outlined in areas such as document organization, style organization and so on.

These days, it’s basically - full on Atomic Method with some of my own twists.

My own high-level framework I adapt and keep to myself in terms of product creation.

Empathy, utility and value.

I’ll let you read the tea leaves on that - as you will.

Seriously though, if you want to get REALLY good, have more impact and thus, charge more, you need to get involved in the business case of what you are designing, who it serves and why that product should exist in the first place.

You want to be hand in hand with the stakeholders.

Thus, it depends on the project.

-

Go to the scene of the crime

While surveying customers can be useful, and we do, I don’t like solely hiding behind a crapy online form and calling it a day. Everyone is doing that shit and people have form fatigue.

I go in the field and get my hands dirty.

I prefer to go to the scene of the crime. The emergency room, the call center, the office, the factory where they make the sausage, the showroom, so I can see the faces of customers in action. Customers in pain, customers being entertained, customers who peace TFO and could give dos cacas about the company. All this, so I can see how the business operates, so I can ask questions and see WTF is going on and hypothesize as to why.

The design approach for me always starts there, getting as close to the problem as possible.

I then dig deep into how the company, its products and services and its site seek to serve those humans and the problem space their offerings exist in.

I get deep into how it works, how does it create value for customers and the business, and ding ding, what economic yield on what I am creating for them do they desire.

That desired economic yield on my efforts dictates if it makes sense for them to even work with me or if so, how do I calibrate my pricing in relationship to the effort, intellectual property and the yield they desire from my contribution.

So funny enough, I rarely talk about “design” with customers, making the logo bigger, my son loves red, so make this red. Design is the baseline. That’s the running water, the toilets, the internet, the electricity and lights on. We do talk design systems, and mostly, my days are spent toiling over how it works, and by nature of how it works, how do our assumptions of how it works serve the user.

In short, the Cliff Notes:

1. Get close to the problem
2. Get close to the user
3. Document and understand business fundamentals
4. Have one single source of truth documenting these understandings.
5. Maintain a constant quest for clarity based on the understandings of the user and business fundamentals.

Good luck.

-j

Dropbox Paper > Sketch > Atom

https://www.quora.com/What-does-the-future-of-PSD-to-HTML-technology-look-like/answer/Dipesh-Batheja?srid=D11Y

Just read this article it was pretty insightful in terms of how the design to development workflow is evolving. I think you might find it helpful for web design approach.

I generally switch between sketch, and coding. I'll start the design in sketch, but a lot of times I change the design after testing it out with some code, so ill make a few 'test' folders and fine tune the design before fully coding it.

Thats about it!

Charles, good question. When you say you are slow, is it you're missing deadlines or you feel you could be more profitable with your time?