Ux and writing go hand-in-glove.If you want a lot of bang for the buck, get your writers involved in the project earlier. You may or may not need an expensive UI designer or an accessibility engineer. But you need your writers involved from the prototype stages onward.
Michael Keating wrote a great post with the provocative title, Houston, Ux is a dead stick. Well worth a read. His main point is that the term has come to encompass so much that is has become meaningless. So, while the concept may be valuable, no one knows what that concept really is.
Here are my thoughts:
- Ux is still critical, but he’s right, we have to define it. By elimination, maybe? Ux is definitely not graphic UI design. Ux is not accessibility, either. That’s two high-cost ticket items it definitely isn’t. What else is it not? Many things, I suspect.
- Ux is where the writer lives. Consistent, useful terminology is the first step. That’s what a writer does all day long. So the writer should be involved in prototype discussions, day one. Writers have an eagle-eye for consistency that few others share.
- Ux improvements can also be derived from “scenario drills”. Tutorial writers are first on the block here. As they tell people how to do things, they find inconsistencies and things that could be made easier.
- Ux, to my mind, could be usefully defined as a “weighted integral of operational steps” coupled with “operational consistency”, where the things you do most frequently have the shortest paths, and where similar operations see a similar interface, with similar operations, and similar labels. (So if a button is “Finish” at the top of one form, it should not be “Done” at the bottom of another.)
- The “weighted integral” can be produced by statistical measurement — if anyone has the time for that — but “consistency” is once again something that writers focus their entire career on.
- I really like the main point of the article: If we can define what Ux IS and eliminate what it ISN’T, we can remove the fear that Ux will add significantly to project costs, and replace it with the idea that it will significantly improve user satisfaction — or perhaps more accurately, the happiness-quotient of the person using the project — all for a nealy INsignificant increase in project cost, or possibly even a reduction, because…
- Bringing the writer in earlier may well make the resulting product easier to write about later (reducing costs in that area at the same time that it increases user satisfaction). At the very least, the writing will be much easier, and will come in on time, preventing cost-overruns in the documentation department. (Statistically, those may well be a decent measure of usability issues! Because the hardest products use are, as a direct result, the hardest to write about.)
In short, when you combine Ux and Writing, you get the best of many worlds, at the lowest possible cost.
Copyright © 2017, TreeLight PenWorks