The story of a true UX tool
Part 4 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 3 was about growing the UX tool, experimenting with exports, adding a level of detail and taking a first step into building scenarios. Since then I’ve been able to present the concept and prototype to 40 UX designers and got some great feedback.
In this article I’ll share the progress of the prototype, how it should facilitate story telling and the story of the tool itself.
Scenario view
In the last article, I set a goal, the prototype should be able to create a scenario like this:
This is what I created with the TrueUX prototype:
This scenario view is constructed with the source files for the individual wireframes. It required me to add some new features, like notes on a wireframe level and a device ‘skin’.
The context of the story
The scenario view is used to tell a story. But the same story can be told in many ways.
When my daughter goes to bed, the last step of the ritual is to tell a story. Sometimes I’m really proud what I made up. So when I go back downstairs, I’ll tell the story again to my wife. I’ll leave out some details, and I’ll probably talk about how my daughter responded to a story twist that I found funny.
The context defines what details matter. The same goes for a user scenario. For instance, if you’re explaining what an app is about, you probably don’t need to show the footer.
For the UX tool, the goal is to make updates once and have all related assets updated automatically. This means that a scenario view, while based on the source files of the wireframes, must be able to hide some details.
Hiding details
In order to hide elements of a wireframe, I used the simplest implementation I could think of. Since it’s likely that more elements should be hidden than kept, I went with a Keep attribute.
Menu
Content
Footer# Keep
Content
A scenario that would hold this wireframe, only shows the Content. The Menu and footer would not be shown. This attribute now would effect all scenarios. If you’d want to tie it to a specific scenario, you’d write it like this # Keep: Login.
Automatic hiding?
The ‘keep’ attribute is simple, but it would be great if the tool could automatically hide the correct elements for you. There could be a minifying algorithm that’s based on things like relative size, the type (video, image, etc) and what elements are re-used between screens.
After talking about it with some UX designers, it became clear that different types of projects and contexts may require different minifying algorithms. For apps you probably want to hide other parts than for web-apps. Eventually I believe you’d probably need a couple of default algorithms, and then be able to tweak them.
Keeping keep
The level of complexity this requires is beyond the current stage of the prototype, so I’ll leave it at that for now. But I did implement the ‘keep’ attribute. The animation below shows the following steps:
- In scenario view, open wireframe
- Wireframe view shows more detail
- Update to check checkbox
- Go back to scenario
- See change made in scenario view
This shows how UX source files can be used in different contexts. I believe this single source of truth will save time when updating assets.
Lessons learned
Working on this update, some potential improvements became obvious.
- The scenario view only holds wireframes. It would make (more) sense to first start with text or image based steps.
- It would be nice to see certain elements larger in the context of a scenario.
- Navigation between files needed to be improved. It took too long to type
o aai.uxsto open the scenario. So I’ve enabledo .3to bring you to the third screen of the scenario and typingowill bring you to the last opened file. More on text commands. - It would be great to be able to edit wireframes inside the scenario view.
- I’d like a presentation mode, just like IDE’s often have.
Dogfooding
With the recent updates, it now possible to use the prototype to design and communicate new features for the prototype itself. This makes me happy.
For instance, I’d like to add contextual links to make it easier to switch between files.
If you look below at the wireframe from step 2, you can see the keep attribute was used to only show row 3 and 4.
Telling the story of TrueUX
Recently I was able to present the TrueUX story at the Design by Fire café. While I felt it was a bit early, I also believe in letting your work collide with reality as often and early as possible. So I talked about the concept, UX source files mostly, and showed the prototype.
The concept resonated
The audience consisted of about 40 people, almost all UX designers and they are curious and analytical people. While the talk was supposed to last half an hour, there was an open and deep discussion lasting well over an hour.
I believe the main concept was well received. They feel the same pain points as I pointed out and are very interested to talk about new ways of approaching UX tooling. There also where some good tips for things to look at, like CSS grid.
The prototype required imagination
The prototype didn’t yet have the scenarios as shown in this article. It required quite some imagination to see how the prototype consisting of only wireframing was a good starting point for a UX tool that ‘goes beyond wireframing’.
The improved TrueUX story
The big advantage of presenting over writing articles is that you get immediate feedback. In conversations with the audience it became clear that the best way to tell the story of the TrueUX tool is to start with the benefits, as told by personal anecdotes. Something in the line of this:
TrueUX is about making UX designer more productive, allowing them to iterate faster, enabling them to deliver better designs.
The main time waster I felt as UX designer, was the grunt work. The boring tedious work of updating assets when the thinking was done. Aligning blocks, renaming them both in wireframes, documentations and presentations. Getting your clickable prototype in sync with the photoshop files..
We need a single source of truth you control that takes into account the complexities of UX work. Not only that, it should support you in those interwoven parts. I always felt uncomfortable when the client requested a feature and demanded a response on the spot. So I’d say something Like “Yes, perhaps the search icon could go inside the side menu, but this might impact other aspects of the UX design beyond the screen we are looking at right now. I’ll get back to you on that”.
Personally I think UX designers that confidently make decisions like that on the spot are suspect. Sales people should have a different personality than UX designers.. or maybe I’m just not as fast a thinker. Either way; I could be, with the proper tools. A request to update the goals of the persona? “Let me show you in my tool which scenarios and screens are impacted”.
Now when I make those changes, I can quickly make them during the conversation. I’ll make a specific ‘Client suggestion’ branch for the project, that doesn’t interfere with the main branch.
“I’ll press this button, and now all assets are exported. My team members get a notification on will be able to provide you with feedback on how this would impact their work.”
While this explains the concept for a broad UX professional audience, there is also a different story to tell. I’ve noticed that for some, the language and text commands part is what gets them excited. They totally see how it could save lots of time and immediately start suggesting features.
What is the true TrueUX story?
The articles and prototype so far only handle parts of the UX work. It will require more prototyping and writing to see where the true potential lies. It’s a story not yet fully discovered.
Next chapters
The main things to work on in the short term include incorporating more UX aspects and creating a web-app sandbox version.
Changes in one area should affect other parts. For instance, updating the goals of a persona should highlight scenarios and wireframes that are impacted.
Sandbox
The best way to learn is to create quick feedback loops. So I’m working right now on setting up a web application prototype for you to play with. No accounts, not yet suited for real UX work, just a sandbox to play with.
Update: It’s live, try it out here!
Stay tuned
If you want to keep informed or have feedback you’d like to share, fill in this form. The next articles can be found in our Proof of Concept publication, and our website.
Next article:
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. I plan to revisit and implement ideas I wrote about in this article in future releases for the app.
Read about it here:
