Not to toot our own horn, but I think we make wireframes that are pretty good...and unique. We include some basic design elements to help clients get a clearer idea of what the final product is actually going to look like. This is unusual since wireframes are mostly used to get a general sense of layout, content, functionality requirements, and heirarchy. Typically, you are not talking about fonts, line weight, use of images, (ie. the visual language) at this stage in a website build.

So, why do we do it this way? Well, we have found that wireframes can be a difficult thing for clients to conceptualize. They understand that this stage is when we are determining the heirarchy of their information and the general placement of content and "calls to action," but if there are not more specific layout details, sometimes it is hard to "see where this is going." Over time, we have gotten more and more detailed with our wireframes so that the final products look more like a grayscale version of the website to be, rather than a simple content map.  

Here are some tips if you want to construct a wireframe the Rootid way:

1. Research. 
   Make sure before you get started that you have looked at websites (ideally with your client) that have similar layout and functionality as what they are interested in. Talk about use of menus, column widths, call to actions, any highlight areas, use of motion, video or imagery done in interesting ways. This intake conversation is probably the most important step. It saves a lot of time down the road if you already know your clients' leanings. Also, we tend to use this as an opportunity to get input from as many stakeholders as possible. By using a nice google spreadsheet with some prompting questions, you can get multiple people's input (and often consensus) before you actually talk.
2. Start with the Home page, but build with your simplest page (and responsive design rules) in mind.
   Since we are a mobile first/agile development shop, we build websites beginning with the most basic page layout first and then work toward the more complex elements. However, as a designer, since I am doing the opposite, and I need to be gathering "love it" and "hate it" information as I go. I present 2-3 different Home page layouts in the first round that show not only options in terms of page heirarchy, but also font choice, shape of boxes (ie. are there a lot of rectangular elements vs. rounded edges vs. circles), and size of content pieces. The more options you show now will help move the design phase along more quickly later.
3. New round = more detail...but be careful not to go too crazy. You do not want to lock youself or your design team into a corner that stifles their creativity later. Keep your wireframes lite and agile. In some of the early iterations I did of these more designed wireframes, I got too into using lots of shades of gray and no textures. Once I entered the design phase, I would find it really hard to invision different home page design options because I had made too many decisions already.

Note: As an agile design/development shop, we have the benefit of designing and building side-by-side so this system of wireframe creation is also much more effecient than if you need to take a more siloed approach where you are passing things off to someone else once they are complete.