Monograph, an open-source framework for creating quick and dirty design prototypes, started as my 20-percent-time project at Xbox Console Design.
The Xbox design team creates and tests new controls and IA patterns cross devices and platforms, many of which cannot be communicated with static images. Without building a interactive prototype, the design team has little persuasive power against engineering in making feature decisions. Some UX problems are only discovered late in the product cycle, costing big in resources. I firmly believe that better designs are reached through hands-on experience, rapid iterations and early feedback.
So why don’t design teams prototype?
There are a few design developers on the team who make Flash or WPF prototypes. They work on a large backlog of requests. It is a painful process for both devs and designers if anything in the prototype needs to be tweaked.
Blend for Visual Studio provides a GUI to create XAML layout. However the UI is a direct translation from the underlying code, and bears the same amount of concepts that are so overwhelming to non-programmers.
There are several design prototyping tools on the market, among them Framer, Axure and proto.io. I see the following factors contributing to the low adoption among our designers despite their willingness to prototype:
- Not cross platform. The design team has a large user base of both Mac and PC, and works need to be transferable.
- No support for controller/remote input.
- Constrained by what’s exposed by pre-packaged components. Creating custom controls and behaviors is often difficult, if not impossible without programming knowledge.
- Add an extra layer to the work flow. Designers must learn a new software, migrate their work to it, and sometimes go back and forth between it and other design tools.
- Risk. Picking a framework for prototyping is a serious commitment. With relatively small user communities, missing features or bugs that are discovered down the road can block important work.
Building a culture
I learned a few lessons from watching my fellow designers’ frustrations. First, the work flow was still too complex. Every extra software to install or 5 minutes it took to configure a project for export, I lost half of my audience. Second, Edge Reflow as a design tool was too buggy and incomplete. I picked it for its simplicity comparing to complete suites like Dreamweaver. Nevertheless, people were still confused by CSS logic and frustrated by its limitations. Third, I introduced too many magic behaviors. For example, the page automatically scrolled to bring the controller focus into view. If one wanted more control over where it scrolled to, they had to go in extra length. It made fast and fancy demos, but greatly restricted what could be built.
I picked up the project again in October, 2016. I recycled some core ideas from the failed attempt. This time I wrote a Illustrator extension based on ai2html. It was good timing since the Xbox One UI redesign had just shipped, and the console design team was in exploration mode. I encouraged every designer on my team to build a new Xbox dashboard prototype using Monograph. I sit with them and watched them work, investigated bugs in their prototypes, identified where it got confusing, and improved the tool on a daily basis.
The outcome of the workshop was very exciting: visual designers who have never made anything interactive was able to build fairly complex, high-fidelity prototypes in just two days:
I went on a promotion tour around other Windows design teams to show off the capability of the framework. I found that the most effective way of training is to take an Illustrator comp from the audience, and turn it into a prototype on the fly. They instantly feel the relevancy of the approach and start coming up with new ideas. By request I added keyboard, mouse and touch support, better GUI, and wrote extensions for special cases. I also worked with designers from the universal apps and developer relations teams to recreate all Windows common controls in Illustrator.
It remains a big deal for a designer with zero experience to commit to building a prototype for real work. It helps give them the sense of security when I’m there to help as soon as they feel stuck. Once a fellow designer with no technical background makes the break through, the testimony from a trusted peer quickly encourages others to follow.
Monograph is used by visual, motion and interaction designers in a variety of product teams today.
Design Decisions And Reflection
Designers are habitual animals. They may be able to handle an one-time hassle of installation, but they don’t change how they open files. A prototype that requires a local host server to execute was way too much trouble for them. This introduced a lot of complexity in code because the prototype has to talk to embedded iframe windows asynchronously via post message. But it’s worth it.
Transparent & Flexible
I don’t believe in black box controls. A designer should be able to get whatever they draw. I introduced a naming convention for objects, so that all settings for the prototype managed and visible via Illustrator’s layers panel. Contrary to common beliefs, designers can learn simple syntax quite well.
Triggers and actions:
Some designers are less organized than others. They duplicate objects to a wrong layer, unconsciously nudge things, and copy and paste from old comps without examination. I put in a large tolerance in defining overlaps for directional navigation. I also introduced and tweaked a smart inference system to determine the identity of unnamed objects.
Never apply implicit logic. This is a particularly interesting trade off. It is commonly believed that since designers “cannot code,” an abundance of interactive logics need to be pre-packaged and accepted as-is. In this project I explore an alternative. To a developer, duplicating the same code block 100 times is bad practice. In Illustrator, laying out or batch editing 100 buttons is trivial work. In Monograph, I ask that designers provide every possible state of the app, managed via Illustrator’s artboards, so that the prototype never has to make a decision on its own. This is proved to have greatly widen what’s possible with the framework.
Nearly every project requires some specific input device or behaviors. I implemented the core with this need in mind. Every input support, triggers and actions are written as extensions. The current version has been used in building some very realistic simulation of the Xbox dashboard, such as most recently used list, background tasks and memory management.
It was suggested by a team member to allow designers to work together on one project. A prototype can be nested in another by dragging it into the other file. It is possible for multiple people to work on separate Illustrator files then assemble them. The departmentalization of components also allows for managing complex app states.