Sketching with computer and a cup of coffee
The career of a designer is often both demanding and challenging. Design is incredibly subjective and each person has their own opinions and interpretations. To ensure your vision is realized you can implement interface prototyping to visually display thousands of words worth of design and development requirements regarding how a system should both look and behave. To take this one step further, RAPID prototyping involves quickly mocking up the future design state of your app or website and validating with a broader team of users (developers, product owners, designers). The term prototype covers a wide range of presentations from rough sketches on notebook paper to full-fledged interactive examples that can often feel like the end product. Getting feedback early can set the stage for the entire project. Responding to feedback in a timely manner and implementing the right approach will allow the rapid prototyping process to accelerate additional productive discussions while ensuring the team is on the same page so they can ultimately deliver an outstanding product.

DO’S AND DON’TS

DO…

  • Set expectations for the scope of the project early on. Inform others that the Rapid Prototyping process is a tool to showcase the design and is by no means the final product.
  • Set yourself up for success by creating reusable elements. Whether it be Photoshop templates, stencils, code widgets, etc.
  • Be open minded and receptive to peers and their feedback. They benefit from your teachings and education.

DON’T…

  • Receive every single comment, change or request to heart and cement it as a needed requirement. Everyone will have an opinion and sifting through the feedback to implement only the critical or productive feedback is an important part of your job.
  • Do not over commit. Make sure you mockup and prototype features that you know are conceivable that can be implemented on-time and within budget.
  • Perfection is not possible. Rapid Prototyping is just that, quick! Which means polishing your design for hours and hours will defeat the purpose. It is meant as a strong guideline and not a pristine creation.

Diagram with Create, Polish and Review

THE ACTUAL PROCESS

Rapid Prototyping essentially consists of 3 main steps:

1. PROTOTYPE/CREATE
Draft and develop the client’s description/wants into a mockup, keeping in mind the UX and best practices.

2. REVIEW
Present your design and prototype to the client and assess if their wants and requests are fulfilled.

3. POLISH
With the feedback in mind, recognize areas that need to be tweaked and refined.

DEFINING THE SCOPE

Rapid Prototypes are not created with the intention to progress into fully functional solutions, they are simply meant to help visualize and craft the user experience of the finished solution. Hence the importance of the next topic, scoping a prototype. Asking yourself a few simple questions can go a long way in solidifying a strong rapid prototype.
Computer with gears and magnifying glass

WHAT?

Decide what actually needs to be prototyped. Choosing large components within the project such as intricate interactions, large scale design features, workflow implementation, are all strong candidates for items that should prototyped out to the client.

HOW MUCH?

Showing off the functionality of key features should be limited to those that play significant roles in the design spectrum. Highlighting small interactions or subtle animations are not useful in Rapid Prototyping since they are time consuming to conjure and will delay the presentation for something with little impact on the overall user experience.

NUMBER OF PARTS?

Typically, the full prototype will have many pieces that form a solid whole at the end. A smart approach would be to start out with a broad view of the project and plant firm roots. The smaller, more detailed items can come later on once the foundation has been established. It’s ok to not know the exact number of working parts that will make up your project, but you should keep in mind, having an outline of sorts that highlights your large bullet points is extremely helpful.

THE PROTOTYPE HEIRARCHY

LOW FIDELITY

The most primitive form of prototyping is merely sketching your ideas with paper and pencil. This is typically an early, Version 1.0, if you will that will evolve into a more formal, detailed design later on. This level is perfect for the raw brainstorming sessions that designers typically have and can alleviate the process of converting ideas to fruition.

MID FIDELITY

In this stage, wire framing and task flows form more comprehensive composites of the end product. A primitive black and white creative can show the intent of an application or website without distraction. These type of renderings are ideal for capturing the needs of the client and give them a fairly clear picture of what you will be generating.

HIGH FIDELITY

These types of rapid prototypes are the most realistic and are a static version of the finished solution. Of course, these are the most labor intensive and without proper planning and a high-level of skill can bog down the “rapid” phase of the prototyping. Even though the majority of these high-fidelity depictions cannot be directly converted to code, they can show the client your clear direction and often instill a higher level of trust with the client.

Fidelity meter gauge

SELECTING THE RIGHT LEVEL

A critical aspect of a project is reading the client and their wishes and in turn selecting the appropriate fidelity grade. It is never a bad idea to begin in the low category as this takes minimal time and can translate your thoughts to a physical being. However, depending on the complexity of the development, you need to identify which stage will convey your design and tailor to the prospective user’s guidelines. Many clients will place a high amount of stock in the look and feel of a product rather than the functional reliability. Knowing your audience is paramount in choosing which fidelity level makes the most sense.

Summary

Prototyping is an unavoidable aspect of interface design and development. It comprises the idea of manifesting ideas and cognitive solutions into a tangible artifact. The idea of Rapid Prototyping takes that one step further and enforces the notion of being both fast and efficient when mocking up a new application or website design. Use any tool that can improve your productivity and effectiveness, just make sure you set yourself up for victory by creating reusable elements for when you inevitably have a large project with a tight deadline.

At the end of 2016 I embarked on a goal to develop an in-house framework for Mercury to use on our internal websites and web apps, as well as client projects. This blog post is geared toward front-end developers looking to make their own framework, and in this post, I’ll talk about approaches I took and lessons I learned during development of the Mercury UI Framework.

Why Another Framework?

At Mercury, we utilize Bootstrap quite often. Many of our client sites use it under the hood. We’ve also dabbled with Foundation, and there are many more out there. The advantage to using a framework is quite obvious:

  • A well-architected UI layer
  • Lots of components
  • Nice documentation
  • Browser testing for free
  • Large ecosystem with examples, tutorials, and add-ons

While we’ve become experts at using Bootstrap, customizing it (tip: use the SASS version!), and extending it, over time I’ve found it lacking in areas and stagnant in new features. Version 4 has been promised for a long time now, but has yet to appear in its final form. After taking a look at the early alpha code, I also felt like it wasn’t pushing itself far enough (there are good things coming, though – flexbox first CSS, refactored cards components, and more). Better responsive components, like tabs and tables? Nope. An off-canvas nav? Nada. Mega menus? Zilch. So, I decided to create a framework that offered more while keeping the things we use most often.

Mercury UI Framework - Components 2

Plan Ahead

Browser Support

Before setting out creating a framework, the first thing you should do is plan what browsers you need to support. This will help inform approaches and effort once you start writing code. At Mercury, we support the latest two operation system and the latest two browsers. That means Windows 8.1, Windows 10, macOS 10.11, macOS 10.12, iOS 10, iOS 9, Android 6, and Android 7 for operating systems on desktop and mobile devices. For browsers, support includes IE11, Edge, Chrome, Firefox, Safari 9 & 10, Safari iOS 9 & 10, and Android Browser. As of late 2016, that covers about 95% of OS’s and browsers in the USA.

Identify Features

The next step in planning is to identify the features you want to build. For my framework, I wanted to create something on par with Bootstrap, but take it further too. This meant including:

  • Accordions
  • Alerts
  • Badges
  • Bands
  • Buttons
  • Button groups
  • Cards
  • Dropdowns
  • Grids
  • Heroes
  • Input
  • Input groups
  • Mega menus
  • Modals
  • Off canvas navs
  • Pagination
  • Tables
  • Tabs – Horizontal
  • Tabs – Vertical
  • Toolbars
  • Tooltips

I also know I wanted to have good documentation with code snippets to copy and paste, as well as a Kitchen Sink of one screen with all components that could be the basis of a projects’ style guide. The table component I created offers 3 different approaches to making tables friendly for small screen devices. Both tab components (horizontal and vertical) change to accordions as well for better mobile usability. I also wanted to make sure I provided breakpoint classes to turn on and off styling, if needed.

Mercury UI Framework - Brand Colors

While identifying features, it’s also a good point to brainstorm how you can make your framework unique. What feature(s) can I include that will set it apart from the rest and make somebody want to use it? How can I provide value for myself, my coworkers, my peers, and for clients? Where can I make things easier and better? Where can I save time for the things I do day to day?

Lastly, identify what you don’t need to create. For the Mercury UI Framework, I made the conscious decision to not include a rotator (also known as a carousel or slider). Much has been written about their poor accessibility, and because there’s more than enough plugins out there, I kept a rotator component off of my features list.

Create A Timeline

After choosing features, the next step is to create a timeline and estimate how much time you’ll need to complete it. The actual time it takes will be different depending on the skill level of the person writing the code, so this should be different for everybody. Also, finding a good MVP (minimal viable product) point for an alpha release is a good idea – you can always have more feature releases in the future. Make sure your timeline includes:

  • Research
  • Building the framework
  • Refactoring
  • Testing (Applause, manual, etc.)
  • Bug fixes
  • Dogfooding (using what you build)
  • Documentation
  • Testing the documentation
  • Setting up hosting, environments, etc.
  • Pipeline creation
  • Code quality analysis (SonarQube, linting, etc.)
  • Code reviews by peers
  • More testing, bug fixing, and refactoring time

Research Best Practices & Industry Trends

Even if you’re a seasoned front end developer, you should take some time to research. In my opinion, you’ll want to target where the industry is going, not where it is now or where it’s been. Is CSS Grid viable yet, or should I stick with Flexbox? What about responsive type? Should I use LESS or SASS? How can Gulp help me? Utilize resources like CSS-Tricks, Sitepoint, Smashing Magazine, and Codepen to gain inspiration and novel approaches. Collect these links and decisions somewhere, like a OneNote or text document, that you can refer back to later. While not everything made it into the Mercury UI Framework, doing this research will inform the code you write. Some decisions, like using the lobotomized owls selector for global margins, will impact the whole framework. Make sure to refer to Can I Use to make sure you’re providing support for the browsers you chose.

Make It Themeable

The framework I created is meant to be used by front-end developers who have the skills to use SASS, so the approach I took was simple: use SASS variables to theme the basic look and feel of the framework, such as colors, border styling, and sizing of elements. I also utilized SASS maps so that developers could easily add or remove breakpoints and alternate colors for components. If you have the time or need, you could go wild and create a theme generator like some frameworks offer. I’d recommend also keeping your CSS code specificity as low as possible so that other developers can easily override your styles with their own without accruing technical debt.

Make It Easy To Use

If you want other people to use your framework, you’re going to need to create good documentation that has examples, code snippets, and explains your architectural decisions. You’ll probably also want a roadmap with where you’re going with future versions, a place for keeping track of bugs, and several ways for people to get your code (repo, direct downloads, etc). One lesson learned is that documentation takes just as long as writing the framework code – don’t leave it until the end! Try and document your work as it’s completed so that othing is left out or forgotten.

Hold A Code Review

If you’re the only one developing a framework, it’s a good idea to get an outside perspective to make sure your decisions and your code make sense to somebody else via a code review (also known as the number of WTF’s per minute). Another set of eyes and a different brain can help you point out confusion, poor code, or generate ideas for improving your framework. You can hold a code review with a coworker, a developer of a different discipline, or a development manager. If you want a truly outside opinion, find a peer via a front-end development Meetup group. Make sure to follow up a code review with actual action, such as refactoring or creating more documentation.

Test It

This may seem obvious, but sometimes designers and developers cut corners by skimping on testing. Be honest with yourself and really put your framework through its paces by testing it thoroughly. This includes browser testing, functional testing, code analysis, linting, and dogfooding your own work. At Mercury, we’ve adopted Applause for testing our websites and apps, and the Mercury UI Framework was run through this service just as any other project. It helped uncover 70+ issues that I was able to correct, giving piece of mind that the code I wrote would hold up on production sites and apps. Your timeline created earlier should include a healthy amount of time for testing and fixing bugs exposed during that process, as well as multiple rounds of testing if you undergo extensive refactoring during development.

Conclusion

If there’s one thing I want to impart in this blog post, it’s that creating a framework is a lot of work. I hope my time spent can help somebody else looking to do the same. By structuring the process into different segments, you’ll be better armed to complete your framework project and produce a better product as well. Also, remember that you’re never really done with a framework, or any development project for that matter. New needs and ideas arise, browser support changes, bugs will be exposed, and you’ll feel the need to refactor your work.

If you’re interested in checking out the Mercury UI Framework, visit the documentation for the site at http://mercuryuiframework.azurewebsites.net/ (pretty URL coming soon).