Growing a UX tool
Part 3 of the series exploring the potential of a true UX tool. I’m building and sharing small prototypes and writing about it. The goal is to gain a deep understanding and perhaps build something valuable along the way.
Part 2 was about the speed of text commands. I’ve asked around both online and offline and early feedback boils down to: Single UX source sounds interesting, interacting looks hard, wireframes look too simple.
Before taking on user scenarios, I wanted to make some improvements based on this feedback.
Improvement 1: Beyond blocks
With last article’s prototype you could created wireframes with blocks. Like this.
Since then, I’ve added block types, like image, button, input field, etc. You can quickly apply these using shortcut commands like tf for block type input field.
Improvement 2: Select by id
The other improvement aims to make it easier to do selections. In order to be able to select blocks that don’t have a name, I needed another ‘name’, based on the position of the block in the wireframe. The . can be used to start a selection by this id. For exaple .3 2to select the second block on row 3.
It’s also possible to type .3 to select all the blocks in row 3. This makes it easier to make changes to groups of blocks faster.
What defines a scenario
I wrote back in 2015 that UX design tools should accommodate more than just wireframing. One of the main aspects of UX design is the customer journey, user scenario, or simply scenario. A sequence of steps describing a specific user experience.
As a UX designer, one of the challenges is picking the right scenarios to focus on. You want to pick your scenarios based on the needs of your users and goals of your clients. Taking into account more then just the screens, and you also can’t limit yourself to only accommodate for the happy path.
You need to be able to quickly explore and go through all sorts of scenarios to get a feel for where the experience might break down, or perhaps an opportunity can be found to simplify. In order to be able to do this, you need to define your scenarios by it’s dependency on a ‘map’ . The possible steps of that can be taken, and how they are related.
Here is a piece of such a map.
One of the hard parts is deciding the level of detail you want to show. Your UX tool should provide a slider/widget to simply tweak the level of detail, so you can change it depending on what you want to think about or who you want to show it to.
Out of such a map, you can then highlight different paths, perhaps skipping a few screens to simplify, so you can tell a story. For example like this:
This is the type of scenario you want to show in a pitch or to a client to explain what is going on. The developer needs to see the map.
Because I’m creating the prototype by myself, I have to pick my battles. Creating a map and scenario editor would take huge amount of time. With the prototype I want to first touch many different aspects, so I can get a feel for how they can elegantly fit together. One of those key aspects is the ability to create UX assets like presentations.
So for now, I’m keeping the implementation of the scenario as simple as possible; Each line refers to a wireframe.
home.uxw
login_dialog.uxw
home_logged_in.uxwBecause the wireframe source file is similar in nature, the prototype can render and edit the scenario just like a wireframe.
This hack allows me to skip the complexities of the map and scenario making, and focus on the UX assets that can be generated.
Generating UX assets
I see three main types of UX assets to generate:
- Presentation
- Documentation
- Prototyping
In order to learn the requirements for these types, I made bare bone export features for each.
Presentation
I made an export that puts each screen of the scenario on a slide with the notes to the right.
Lessons learned:
- It can be done.
- Within the tool, there is a need for different wireframe renderings. For instance, in this case the row numbers on the side only distract and could be discarded.
- Many more features are required to make the presentation usable in a professional context: slides related to project context (stake holders, context, etc), scenario/map overview, persona’s, client logo, contact information, templates, clickable elements, and improved annotations.
Documentation
In the ux source article I made the case for readable source files that can be used as documentation. The current source is very close to looking like this.
Wireframe: Edit Scenario# Preview------------------------------------------------------------
| menu |
|----------------------------------------------------------|
| | | |
| command input | pers. img | persona txt |
|----------------------------------------------------------|
| txt render | source | ..... |
|----------------------------------------------------------|
| |
| |
| |
| source view |
|----------------------------------------------------------|
| ... | save source |
|----------------------------------------------------------|
| | |
| incoming links | outgoing links |
------------------------------------------------------------# NOTES
source view: would be nice to have highlights based on existence of files
outgoing links: based on last item in all files# LAYOUT
menu
command input,pers. img,persona txt
txt render,source,.....
source view
...,save source
incoming links,outgoing links# DETAILS
menu ; height=1 type=”header” attention=0
command input ; width=2 type=”field”
pers. img ; type=”image padding” attention=3
persona txt ; type=”paragraph”
txt render ; height=1 type=”tab open” attention=2
source ; height=1
..... ; height=1 width=2 type=”paragraph”
source view ; note=”would be nice to have highlights based on existence of files” height=4 attention=3
... ; height=1 width=2 type=”paragraph”
save source ; height=1 type=”button” attention=3
incoming links ; type=”field”
outgoing links ; note=”based on last item in all files” type=”field”
While it’s more readable than HTML, it’s not yet documentation.
Potential of exporting documentation based on this file:
- In a Word or PDF file you can include screenshots that take care of communicating layout, and attributes like height, width, attention and type.
- Generating word documents seems possible. For instance using the python library python-docx.
- It would be nice to have a way to version the documentation. Showing who changed what and where, preferably automatically generated.
Prototyping
There are many ways to prototype, but creating clickable HTML files seems to be the most convenient solution. Luckily, the UX source lends itself well to generate HTML. In this example I used bootstrap to style the blocks.
Source of wireframe:
Export; type=’header’
Select file type
HTML; type=’radio selected’
PDF; type=’radio’
export >>; type=’button’
footer; attention=0It was able to write the code for this simple HTML generation in less than a day. While it’s limited, it shows the potential.
Lessons learned:
- Types (buttons, input fields, etc) are easy
- Nesting (blocks inside blocks) is hard
- The UX tool should be able to include plugins that allow you to create HTML exports of all sort of types, not just based on Bootstrap.
- Also buttons could be made clickable so you can generate a working prototype.
Where to grow from here
I recently met Jochem, he’s also from the Netherlands and has a background in online marketing and writing. We have been talking a lot about the potential of this project and have decided to make a conscious effort to explore how this concept and prototype can be transformed into a real product.
In order to that, we want to gather more feedback and make it clearer that we are looking for a developer to join our efforts. So we are going to make a simple website with an online sandbox environment where people can play with the prototype.
For the future development of the prototype, I’ll be using a real project as a reference. It’s a project by my friend Zoë, called Animal Alert International; an app that helps you signal animal cruelty and take further actions. Take a look at the scenario below.
I’m planning to use the assets she made in Illustrator and Word as a reference for what a comprehensive UX tool should be able to generate. To be more specific: The first goal is to make it possible to generate as close as possible this exact image containing the 8 steps.
This means the following features get priority:
- Rendering with multiple simplified screens
- Rendering of device surrounding the wireframe
- Allow single image (like .1) as a step in the scenario
- Some element features: map, long texts, icons
That’s it for now, let me know what you think in the comments below. Also, If you want to get involved with testing or otherwise like to give feedback, you can fill in this form and I’ll send you an e-mail and we can get in touch.
Update November 2022 — My new low fidelity UX app
I created a low fidelity UX tool for the mobile phone. For now it’s about capturing your UX ideas while you are on the go, in the train, in bed or on the toilet. For mobile typing doesn’t really make sense. But I’ll add exporting of .ux files in a future release.
Read about it here:
