I think visually. I find myself often going up to the white board at customer sites to draw out something we're talking about.
This is not new. What is new to me is how many times recently coworkers have made comments about the diagrams I've made:
- "Did you draw those pictures? If so, outstanding! ... Very well done! I especially like..."
- We've been going in circles trying to communicate that to the (business people or developers) and it was much easier to walk through that diagram
I am not (just) trying to toot my own horn. It's just that I am not a designer or an artist. I've sort of trained myself to use a visual form of communication first, and I've found it to be very effective. I use very simple tools. I make drawings that only take minutes to create. And I've learned a lot working side-by-side with Summa's talented and very innovative designers.
Here are some techniques I use every day, from lower to higher fidelity:
The lowest hanging fruit is drawing on the white board. These are quick, collaborative and can be persisted via a quick camera phone snap. Most technologists use this technique.
This is still pretty quick. It can be done collaboratively or solo. Often overlooked, but an invaluable step even just as as a precursor to other more lasting forms of diagramming. A sketch can be completed in minutes and is often helpful just to figure out what sort of diagram you want to make.
You can show this to someone (a peer, a business owner) and ask, "Does this help you understand?" And it can be persisted by spattering a few across the walls, scanning, or "cleaning them up" digitally.
Google Drawing (or other cheap/quick drawing tool)
Note: Visio does not qualify (at least for me).
I use Google Drawing (create > Drawing in Google Drive) whenever I need something to look nicer than paper/pencil but I still don't want to spend a lot of time on it.
It doesn't offer you templates or UML. But it is fast. I drew the picture to the left in probably less than 20 minutes (well the first draft, we iterated on it many times -- which after all is the point).
These drawings are not expected to last. They are meant to be conversation topics that will get people to say, "Oh I wasn't thinking that at all. Can you move this over here?" And then you can, quickly. Once design is done, they don't need to be updated. If they do, then maybe Visio is a better bet.
An alternate cheap drawing tool is PowerPoint. PowerPoint comes with the added bonus that multiple drawings can be put together in sequence to tell a story. For example, the diagram above is really a series of four diagrams that together tell how a team I was on used git for developing feature branches. This was just the beginning, there was some further documentation with git commands with comments referencing these letters, but it was much easier to see the stages this way.
PowerPoint does not require the team to all know or like PowerPoint. In this case I used it as a tool then exported the rendered slides as images to build this big graphic.
PowerPoint (a little more complicated)
PowerPoint also has the ability to animate, to build drawings on other drawings. Here is an example of a diagram my team was putting together at a customer to demonstrate a three-phased project. The changes were incremental so we put together this slide and animated each phase building on the next.
Wireframes (in this case, Balsamiq)
When I have the time and the need, I will create lo-fidelity wireframes. In a perfect world, these are done by a real UX designer who has real training (again, Summa has a bunch of them). But in many cases, UX designers are not available to me, and I still believe it's essential to think about the users first. So I take off my developer hat for a moment and try to work with the users or their proxies on the user experience. Even for UIs like that above, built for QA testers of an application, it seemed better to make it easy to use than not (or not to think about usefulness at all).
So I started with some paper/pencil sketches really fast (minutes), built out the above wireframes still pretty fast using Balsamiq (1-2 hours) and very quickly was able to get tangible feedback on what sort of functionality the feature was missing, should add. For example, I had completely misunderstood that last box. And I hadn't written a line of code.
I hope most of you read this and think, "Heck, I could draw those!"
Once you have the "Heck, I could draw those!" feeling, sit back and wait for the confusion, missed opportunities and costly rewrites to diminish. It really is true that a picture says a thousand words, especially when communicating across disciplines, backgrounds and between business and IT.
For more on low-effort drawing, check out Back of the Napkin by Dan Roam.