After understanding the foundations of the problem and subject matter through Discovery and exploring all the possibilities through Imagine it's time to get into the details and start creating artifacts that begin to form the experience.
There's different levels of fidelity when creating and picking the right one really depends on what your goal is. For example, do you need to better understand how people get from point A to point B? Flowmaps are fantastic to understand a person's digital journey. Or do you need to focus on a specific behavior or point in the journey? Then detailing the UI will be imperative.
Not every type of UX deliverable is needed for every project. Projects typically need different fidelity levels of artifacts produced. During the discovery and planning of the project you will get a good idea of what type of deliverable is needed.
Below are some key artifacts and when and why to use them.
Flowmaps
Flowmaps can be used to document existing user flows, changes in flows, or communicate net new flows. Their purpose to to help visualize how people get from point a to point b. I find flowmaps very helpful because they help set the context of the overall experience before diving into the screen by screen details.
Not every site or experience is linear. A sign up process of ecommerce site, for example, tend to lend itself well to flowmaps. But news sites where people go in and out of content may be better served by site or content maps. It depends what you need to explore and communicate to your stakeholders.
Flowmaps are a great way to set the general context of a person or segment's journey before diving into the screen by screen details.
There are (surprisingly) very few tools to help effectively document and create flowmaps. Two current front runners are Axure and Overflow.io. I love these because they allow for dynamic flowmaps meaning I can move screens around and the connectors between the screens automatically update. Others are much more static and you're relegated to drawing each connection which can be very time consuming.
In future articles I will dive into these tools and how I use them to document and communicate flows to stakeholders.
Wireframes
I recently being toying with adding an addition to my home. By recently I mean, I've been thinking about it for over 10 years and have now taken the first steps. It's a big decision with bigger financial implications. One of the first items of business was to hire an architect and review the survey of our home. If you've ever seen a survey, you know it's a bunch of lines identifying boundaries, permanent structures, squiggly lines indicating where our fence go into the neighbor's yard (whoops). It's essentially, a wireframe. A generalization of a product that gives a good indication of how to build without going into the details of the design itself.
Wireframes in UX have been falling out of favor in preference of higher fidelity visuals and with the advances of Design Systems and open source frameworks, I can understand why we are moving towards quicker higher fidelity deliverables. But much like architectural drawings, wireframes serve a vital role. It allows us to quickly align on overall vision and structure before getting into the details of the design. So low-fidelity wireframes still have a place. Much like sketchboarding, they allow us to quickly put ideas down on paper, try different organizations of components before going too detailed into the process.
As we finesse designs and generate more and more assets, making changes and pivoting to a new direction becomes harder because of the time and financial implications it brings. With wireframes we can test out ideas and assumptions without a large investment in time and effort so we are more willing to throw it out when a better idea comes along.
Mock Ups
Mock ups (also known as comps) are the next level of fidelity and typically focus on the "pixel-perfect" aspect of design. It takes into account brand, element design and interaction. Mock ups is when everything starts feeling real. It's also when there's a lot more time and effort invested on the details.
I am happy to say there are tons of choices for tools for creating mock ups today. A decade ago we were relegated to using a photo-based tool for digital interfaces. Now there is over a dozen tools on the market to choose from. It will depend on you and your organization's specific needs and preference which tool or combination of tools will work best for you.
The choices can be overwhelming so in later articles I'll work to explore some of the hottest tools out there.
Prototypes
As with mock up tools, today we have an embarrassment of riches when it comes to prototyping tools and technologies. Depending on what we are trying to communicate with the end deliverable, there's the ability to create porotypes for animation, interactions and flows. And if you're a designer that can code, creating HTML-based prototypes is still my personal favorites.
We'll get into some of the prototyping tools and techniques in future articles.
Design Specs
I love documentation (things like these articles that share knowledge and experience) but I am not a fan of design specs. Though at times, I will admit, they are a necessary evil I find that they often take a life of their own and designers are relegated to spending more time documenting and less time designigning.
There are valid uses for design specs, things sometimes need to be annotated and described because the mock up or prototype does not get into those details. And there are times where time difference with developers make design secs necessary, but they should never be the bulk of the work designers are spending their time doing.
I recently worked with an agency that managed to deliver a 32-page design spec to describe interaction on a log in screen… a log in screen.
That document probably cost the company thousands of dollars and pushed an already late project to another release. If you need 32 pages to describe a simple, ubiquitous interaction, there is something wrong with your process.
With the proliferation of design tools specifically crafted for digital experiences there are simply smarter ways to quickly or auto document as you go. Zepplin and Invision Inspect are some of the tools out there today making it easier for developers to grab code specs without the need of additional documentation. For non-dev annotations leveraging Invision notes or a google document makes it much faster to document as you go and document only what's necessary so everyone can instead focus on what matters - the experience.
In subsequent articles we'll talk about some additional design spec guidelines, ways to make the successful and I'll share some templates to help quick start your next spec deliverable.
In Summary
The Create phase is when things start coming alive. It's an exciting time, no wonder why we always want to go right into creating. The hard part is making sure you have have identified the right problem and have a good foundation before creating. UX is about looking at a problem and needs of a business cohesively so it's important to temper our joy of creating to ensure we have all the understanding we need before getting down to the pixel. And even as we create it's important that we continue to Validate along the way.
