Creating a true UX tool — part 1: source files
In my last articles I explored the guiding principles of a true UX tool. At the core is the thought that UX design is much more than designing an interface. I’m following up by trying to create such a tool. Not all at once, but by building and sharing small prototypes and writing about it.
As a quick recapture, here are the core requirements as stated in the first article:
The core of the tool is formed by how the different parts are intertwined. Design elements like personas, customer journeys, information architecture and pages are all connected and used in relation to each other.
Makes communication easy
The tool is made to communicate the (state of the) design to different stakeholders. This includes sending and receiving feedback, sharing assets and different views on the design to support different communication needs.
So when I’m creating my prototypes, I’ll try to hold true to those requirements. For me this means to start at the bottom; the seed out of which to grow everything, an open language format that is holistic at it’s core, is easy to share and human readable.
When I was in France with my family on holiday, I started thinking (unlike most romantic comedies) about UX tools and had an urge to build something. It had be build-able without internet and not get me into too much trouble for ‘always being behind my computer’. So I decided to build a simple proof of concept program that explores the concept of UX source files.
Why we need UX source files
Perhaps relevant to mention that for a while now, I no longer ‘draw squares for a living’, I’m now paid to write code. That code explains how a program should work in a human readable way. Other software turns that source code into a program. I believe we need something like that for UX.
UX designers use lots of files. Photoshop files, Word files, Axure files, etc. Or they don’t and then there is only an online account from a company that may or may not exist 3 years from now. These closed file types and accounts don’t feel very comfortable to use. I prefer an open alternative.
You could say the functional design document is the text based source for the UX design, but there is no software that turns that document into the different assets you need to explore and communicate your design.
The goal is to have one or more files that reads as close to a functional design document as possible, but is much more powerful. Let’s call them .ux files for now.
.ux files are:
- Text based
- Human readable
- Written using rules that allow you to express and connect different aspects of UX design.
With .ux files you can:
- Easily share, thus prevent vendor lock-in.
- Generate documentation and other artifacts like prototypes.
- Make use of existing tools for text manipulation, like text editors and version control.
Current languages don’t qualify for these files. How do you write a user scenario in HTML? And how do you link a persona to a user scenario in a .doc file.? My prototype can be seen as a first sketch of a language for .ux files.
The .ux proof of concept
I made a small tool for UX designers. At the moment it can create create source files for wire-frames; you provide text input, and it returns a text-based wire-frame. Then there are some commands to manipulate your wire-frame and you can view the source file with the command
Now let’s do some updates.
So I started with these text based wire-frames, perhaps nice for the front-end developer to add at the top of the source code. But if you want to put it in a presentation or print out to sketch on, you’d want a normal image.
You can also take the source with you. As you can see, the source code is a bit more readable as the commands that I entered. At the top is the layout, and below are the details (attributes) of the blocks.
You can try it out
Feel free to play around. The core rules for creating a wire-frame are that the
, splits blocks horizontally, and
- and lines split blocks vertically. For more help, type
/ux-help in Slack. It only does wire-frames for now, but the whole point would be that it eventually could cover all aspects UX design.
Click the button below to add the slack bot to your team, this will bring you to the permissions screen of Slack if you’re logged in:
While the prototype only covers a basic form of wire-frames, here you can see how a .ux file for a small UX project could look like that covers more UX design aspects:
True UX tool
// This document describes different aspects (goals, personas, scenarios, wire-frames) of the UX design of the "True UX tool" project.
// can be linked to user scenarios
// Each line is a goal. "Use" is name, the rest description.
Use; Stimulate usage of slack bot
Follow; Stimulate people to "Follow" on Medium
Feedback; Stimulate feedback on .ux language, and tool in general
## Persona: Mike
25 male UX designer at a big company who would like to contribute to the field of UX design.
## Persona: Anne
33 female works at JetBrains, has time to do research at her job
## Scenario: Get feedback
// A scenario is always from the perspective of a persona
persona = Mike
// A scenario is always related to at least one goal
goals = Use, Feedback
// Each line is a step in the scenario
Browses Medium looking for new UX articles
Reads article 'A True UX tool'
Clicks link at end of article to 'Creating a true UX tool'
Clicks link to (at moment non-existing) website
Wire-frame:Home; learns about goals, is interested to learn more
Wire-frame:Home; clicks 'About us'
Wire-frame:About us; reads and wants to get involved
Sends email, based on contact in footer
Sends persona:Anne a link to the articles.
## Wire-frame: Home
// Set extra attributes to components of wire-frame mentioned above
content; note"Explains core mission above the fold"
## Wire-frame: About us
content; note"Tells who we are, what we do, etc"
// Details for level ##, both "Home" and "About us"
footer; height=3 note"should include social media links"
You can imagine that you could use it to generate flow charts, component documentation, clickable prototypes, a presentation on different flavors for a specific component, etc.
What I learned by building the slack bot so far:
- There should be a difference between the language for creating and manipulating .ux files and the source files themselves. Commands should be short and easy to type, like
footer;w8h1for a footer that’s 8 columns wide and has height of 1. But in a source file you’d like to read
footer; width=8 height=1.
- It’s fast. Even now, there are use-cases where this prototype can be faster to use than sketching it on paper, or using paint.
- Text based input doesn’t make sense for everything. So yes, while
/uxw-renameworks, it would be nice to double click on a block to change the text. I’ll probably make a GUI prototype later.
- I’d like the source code to use Mark Down symbols in a way that it would look good in a markdown reader.
For me, the usage of .ux files makes sense. It provides a standard on how to describe different aspects of UX design and it allows for tools to be created that make use of them.
It’s hard to judge the real value without feedback from real users and without expanding the tool into more aspects of UX design. So it would be great if you could help me out by checking out the slack bot and letting me know how it could be improved by writing a comment.
Next up, I’ll be exploring a feature described in my first article:
Make it easy to create rich persona’s and customer journeys
If you’re interested, tap the follow button below to let Medium notify you.
p.s. If you are (just like my persona) Anne, and you just got an e-mail from Mike, let me know if we can partner up.