Hmmm… you’re probably wondering. Why am I writing about UI design on a technical writer’s site? Good question. Perhaps it’s the product tester in me.
A project I collaborated on a while back was considered the granddaddy of them all according to my project manager. Monster budget. Tons of developers. JIRA burn down charts galore.
The only thing missing was logic in the product they were building. Okay, let’s take a step back. Even before the design code was firing on all cylinders, they made a grave mistake.
Adaptive Prototypes vs Responsive
Which would you rather do? Invest time and money solving a puzzle or predict every conceivable target mobile device platform to run your software product? Duh! Puzzles are far cheaper and lot of fun on a cold rainy days.
The difference between adaptive website design and responsive are night and day. One is far cheaper (responsive) and easier to hardwire CSS into your design.
Adaptive requires individual templates for every device. Ouch. Don’t forget every template needs to be maintained and updated for new releases.
Unfortunately, the project design team hired a developer who was an Axure RP loyalist. So every shred of the wireframe was built using the adaptive approach.
Granted, there are some work arounds but honestly, it’s a royal nightmare. To add even more fuel to the fire, the sales team and service reps were absent in the planning. Understanding some of their customers used tablets to access their system was a major oversight.
Okay, I get it. You don’t think you’re building a mobile application since all users will be logging in to a highly secure site. But many companies these days juggle workflow from desktops to tablets.
Oops: We Forgot End-Users
Don’t take my word for it but reverse-engineering your product is usually a good thing.
Understanding ever fiber how your users will access and throttle your application is critical. Hardly my place, but I wondered why there wasn’t any discussion about responsive design in the early sessions. Hmmm…I thought. Why would we be build a product that isn’t designed for all devices at the core of the CSS?
The technical writer in me wondered more about UX than the developers. Granted, there were many brilliant people on our project. But this oversight turned out to be devastating as we began UAT.
Simple questions are how I approach all documentation projects. Ones such as:
- What devices will users access our content?
- Will the documentation be built into the UI?
- If yes to #2, can I get access to building it?
- If no to #3, why?
Another issue which needs to be solved early on is updating online content. Often, documentation is an after thought. Not always but more than you think. My experience has shown engaging technical writing teams early in the project always means better UI/UX.
Two Approaches To Online Documentation
The first is jamming it ‘somewhere’ as the developers like to suggest. Unfortunately, help guide standards are far more dynamic these days than the old 394 page PDFs we use to write.
Beware: any time a planning committee suggests user documentation will be figured out ‘eventually’ should make you cringe. Late-stage SDLC user documentation planning is never good. Especially when you have 10,000 users who suddenly start flooding your company with service tickets. Or worse, calls.
The second approach (smarter) is getting your writers involved with dev from the get go.
Remember, if you haven’t built a WYSIWYG for your technical writers, all the documentation will need to be coded by a developer. Although not common these days, I have suffered through a few projects whereby I had to migrate my content into Atom and carefully format it within the code.
Writers can be a crafty bunch. I ought to know. We represent that brick wall between happy users and confusion.
Despite SDLC politics, I have been on a teams that were very open to accepting me at the design table. It’s not rocket science. However, safeguarding an easy user experience is mission-critical to polished product.
Know Thy Place
Much of this post focusses on a hybrid approach of technical writing and UI/UX development. For many organizations, well-defined roles are central to documentation and production.
In these types of situations, accountability with writing and interviewing are essential. Some corporations have little oversight with writing milestones. The writer crafts on his or her schedule. If you’re a technical writer, beware. Most IT companies need your copy now, not in a week.
Knowing thy place as part of the team hinges on your ability to fully comprehend your product and target audience. I’ve worked on some projects where the writing team felt a sense of empowerment completing tasks willy nilly.
As part of the team, technical writers should be responsible for protecting the end-user experience whether with words or visuals.
