There are as many approaches to mockup as there are tech stacks and team variations. If you only have one approach or tool, you may consider how it is limiting your workflow and process. What you choose may be dictated by several things:
- Who on the team will be modifying the mockups and what is their level of expertise?
- What is the technology stack? If your application uses specific libraries, you may be better off working with those libraries instead of against them.
- What are the expectations of the client? Are they comfortable with static mockups or would they benefit from clickable mocks?
Why We Need Mockups
Hands down, the number one reason we need mockups is that they facilitate discussion and begin to make ideas tangible. As all of us have experienced, what one person says or means can be misinterpreted in many ways. Getting the idea into a tangible form gives another dimension to that meaning—a dimension that is also open to misinterpretation. Mockups should be both the results of a discussion and an impetus for discussion. Because of this, my number one rule for mockups is that they should be easy to manipulate, preferably even live.
But mockups have their limitations. They don’t and shouldn’t capture every scenario and user story. It can be a good idea to discuss with the client and your team members which scenario or user story is best illustrated in the mockups if there are many, or pick a story that hits many touch points and set expectations before discussions. Additionally, having other forms of capturing states and behaviors such as requirements documents is ideal.
Live Code, Design, and Reusability In Mockups
There are many who pledge “no design and no code,” in their mockups and feel that mockups should be thrown away. They want clients focussed on the ideas at hand. I have several issues with this approach. I use design as a communication tool and I use code as reference, and both of these things are reusable later in the process.
Visual structure allows the viewer to move through a page in an orderly way. Elements with high contrast and color draw the eye faster than those without. By using visual structure in my mockups I can identify key elements on the page for my clients without having to explain it. That visual structure often makes its way into the design phase, however, it doesn’t have to.
Using coded elements in a mockup allows for me to get there earlier. There are times when I don’t want to custom design elements like fields or radio buttons. I have had times when developers have delayed production because they are unknowingly waiting for custom scrollbars from me. Sometimes design can hurt a process. Additionally, I often start with available libraries or themes. If I have those available when designing, I work with it rather than against it and therefore speed up production.
1. Scraping Existing Screens, Working in a Dev Environment, or Using Existing Libraries
This option is best used when modifications need to be made on existing screens or a redesign, designers have the technical skills to execute it, or developers already have a strong sense of the development and functionality of the product.
- The most reusable and fastest production time of all the options.
- Can be beneficial when working with a Java app or other tech stack that needs to be compiled.
- Allows designer to write CSS which utilizes existing selectors and structures, so there is less interpretation for the developers to do.
- Allows developers more freedom and participation in the page design and development
- Tends to create designs that work with the tech stack (see design con).
- Can be time consuming if there are many complex pages or the code is designed poorly.
- Good intentions can lead the way to wasted efforts if communication between team members is not maintained.
- Can involve complex setups and developers skill sets.
- Design can be sacrificed at the expense of functionality. (see tech stack pro)
- Git and other version control/collaboration tools
- Any tool that creates a dev environment that allows designers and developers to see how their work interacts...the list is endless.
2. Clickable Mockups
Clickable mockups allow for a little bit of design and a little bit of code. The way to make this option successful, however is to plan better. Start by using the tool to sketch and get the structure down. Then add in the interactivity. One option here is to also take a step back from your tech stack and look at ways to add a templating system. Allowing your designers the ability to create their own layouts is a great way to foster more design in your products.
- Allows designers to build a reusable component library.
- Clients get to bang around and visualize workflows, which is particularly beneficial when the work requires several roles or complex workflows.
- Allows developers to reuse existing CSS rules, elements, and selectors.
- Added time to create clickability.
- Designers need to be prepared to address interactivity at the same time as structure.
- A little less flexible if structure changes happen after interactivity is added.
- Twitter bootstrap
- CMSs, such as Wordpress
- Any system or language that allows for templating with HTML, such as PHP, Django or AngularJS
3. Paper or Unclickable Mockups
If doodling on Postit Notes® works for you and your team, then it is no less valid than any other approach. I have used the gamut of mockup tools, including non-traditional tools like Indesign and PowerPoint.
Though some of the tools mentioned here allow for the addition of links and hotspots, I am calling them “unclickable” because their elements such as textboxes and radio buttons are illustrations rather than clickable HTML. Additionally, applications such as Photoshop and PowerPoint can be exported to HTML, it is not their main purpose.
- Anyone can do it. You don’t have to be an artist to draw a few squares and labels.
- Very flexible and can be designed live.
- Not reusable for code.
- Limits the interaction between developers, designers, and clients.
- Scrap paper, Postit Notes®, or plain old napkins
- Photoshop and other design and illustration products
- PowerPoint and Keynote
My decision on which tool to use has never started with “The industry standard…” or “The most featured…”. I typically make a decision on which tool to use based on who I’m working and collaborating with and what is the fastest tool for the job, and sometimes that tool is a napkin. The point to a mockup is not standards. It is how fast can you make changes. And here is my favorite industry tip, “If I am the only one licensed and approved to make changes, I am a bottleneck.” That is not to say that everyone should be allowed access or that training and guidance shouldn’t be given. It is just to say that job security should not be granted with a software license.
The perfect, all-encompassing mockup tool has yet to be invented, in my opinion. My ideal product is one that allows for flexibility and interactivity. It integrates traditional specs docs and diagrams with clickable mocks and interactive elements. Additionally, it allows for reuse and is exportable to a variety of template systems and possibly design programs like Photoshop. So what do we do until this all encompassing tool is developed? My answer has been to keep my tool box as well stocked and flexible as possible. What are some of the tools and strategies you’ve employed?