Many UX designers are starting to understand the value of prototyping and designing products with real code in the browser, as opposed to creating flat or clickable mockups in Photoshop or Sketch for clients to sign off.
While there are a number of plugins, work arounds and techniques for creating prototypes from flat visuals, as well as many decent dedicated prototyping platforms (UX Pin, Axure, Marvel etc) my go to tool of choice is always Webflow.
It’s a fantastic design tool that focuses on designing visually in the browser, and has already been embraced by companies such as IDEO, Adobe, MTV & Nasa, as well as numerous independent design agencies and freelancers.
There are a few reasons why I favour Webflow –
- You can jump straight into creating layouts in the browser and seeing how they respond across multiple devices from the get go. No imagining how the finished product will behave and look.
- Having the prototype already in Webflow allows you to transition nicely into the UI/Design phase of the project using the signed off prototype as the foundation. I’ve seen agencies and teams face big conflicts, not to mention waste a lot of time by using one piece of software to build prototypes and another to craft the design, but Webflow solves this disparity.
- Webflow lets you export production quality code that will impress even the most pious developers with it’s clean, semantic structure and nice indentation. This code export is also perfect for rapid turnarounds and works as a great front-end framework for CMS based projects. Very good.
Webflow is great for getting things built quickly and inviting feedback from stakeholders and clients, especially if you work in a fast paced environment where prototypes need to be created and iterated on…lots.
My typical UX/Design process is as follows –
Let’s see in a bit more detail how Webflow sits within this …
UX & Planning — This is the requirements gathering stage before I kickoff any prototyping activities. Here details such as User Journeys, Types, Personas, Workflows and the Sitemap are gathered and compiled in a report that serves as the basis of my prototype and design.
A typical sitemap that i’d create and use would look something like this …
Prototype — Here I launch straight into prototyping the key screens and user flows of the product in Webflow. We will look at this in more detail later on, but it’s this point I map out all the site’s pages and screens according to the proposed sitemap, and have them all connect up and link to one another as they should be on the final product.
This gives the client the opportunity to understand at a very early stage how users will will navigate through the site, rather than having to fill in the blanks or use their imagination, as is often the case with static wireframes or even clickable mockups.
At this stage the prototype also goes through several rounds of reviews and iterations (as many as needed to arrive at the right solution) before a sign off is agreed with stakeholders or clients on things such as content hierarchy, user flows and general page layout.
Design — With the prototype signed off I then move into designing the UI of the product all within Webflow. As mentioned earlier, having the means to create the prototype and then mould it into a fully finished UI all within the same software makes the transition from prototyping to design very smooth and integrated.
To begin with i’ll deliver a basic prototype to my client or stakeholders, with the aim of achieving the following objectives –
- To show them how the user journeys and using the product actually feels. It’s one thing seeing a static sitemap or diagram, but quite another having something to navigate through on your desktop browser or mobile device.
- To agree content hierarchy and general page/screen layouts. Similar to the point above, it’s one thing to see content in a Word Doc or PDF but quite another for a client to actually understand how it will appear to the user in the context of the product.
As with many prototypes, the appearance is completely un-styled and is presented in greyscale.
Nothing worse than launching into responsive prototyping or even detailed UI design and then having to re-arrange pages and layouts half way through because we haven’t agreed content structure and hierarchy up front.
It’s one thing seeing a static sitemap or diagram, but quite another having something to navigate through on your desktop browser or mobile device.
After the basic prototype is signed off, Webflow’s true beauty for crafting responsive designs really begins to shine. Using Webflow’s UI and clever CSS tools, I then prototype the responsive layouts and functionality across the four main responsive breakpoints –
- Desktop (991px and above)
- Tablet (990px and below)
- Mobile Landscape (768px and below)
- Mobile Portrait (470px and below)
Designing in this way really allows clients and stakeholders to understand how the finished responsive product will display and function across a variety of devices very early on in the project, something that is often overlooked with static visuals.
Progress & revisions
Webflow allows you to publish your project to either a webflow.io domain or export and host the prototype code on your own server. This allows easy sharing of simple URLs for client review and sign off that can also be password protected.
One thing i also find hugely beneficial about Webflow is being able to revise and update different versions of your project all within the same software.
After each review and sign off stage with my clients, I will duplicate the project within Webflow and append a new letter to the domain extension, denoting a revision. For example, a typical project might look like this –
- client-name-prototype-a.webflow.io (revision 1)
- client-name-prototype-b.webflow.io (revision 2)
- client-name-prototype-c.webflow.io (revision 3)
- client-name-design-a.webflow.io (revision 1)
- client-name-design-b.webflow.io (revision 2)
- client-name-design-c.webflow.io (revision 3)
And so fourth…
This allows me and my team to easily keep track and refer back to different versions of the prototype or design for whatever reason. If a client wants to see an older snapshot of the prototype, nothing needs to be updated or re-published from my end, I can simply refer them to the relevant link.
While I still think software such as Sketch is great for creating static visuals, I have found that Webflow has completely changed me and my team’s way of prototyping and designing.
We’ve used it to deliver high value design projects for big London based clients such as City of London & Southbank University, as well as smaller funded startups that required a very fast turnaround time.
I wrote this post to try an espouse the benefits of what I believe to be an awesome piece of software that is truly at the cutting edge of how we will be making the web over the next few years. I see a lot of organisations with bloated design processes still creating visuals in software like Photoshop and I believe there is a better way!
Let me know your experience using Webflow and your thoughts.