New
& Notable> Workflow in UI Design
Workflow in UI Design | 18 Tips
Tip #1: Start Story Boarding Workflows BEFORE You Design
An early focus on user experience means including them at
a very early stage in software development. This is surprisingly
difficult for software developers due to secrecy, legacy,
poor process or all three. To get user feedback use mockups
or storyboards of the workflow the product is to automate.
The workflow is essentially the list of actions that the product
should perform in accomplishing the User's required tasks.
If you run short of development resources, suck it up and
use Powerpoint. It can help get something together to show
what you believe the workflow should be. Because a .ppt is
static/non-functional it should only be used to test your
workflow assumptions with some core users or even potential
new users. This is the bones of the software. We'll get to
the flesh soon enough.
Tip #2: Understand What Users Are Trying To Accomplish
You can't prototype user workflows well until you understand
what the user wants to accomplish with your software. You
need a very clear understanding of what the product is supposed
to do, from a task perspective. Features are meaningless if
they aren't part of a Users normal workflow. When was the
last time you used the Document Map in MSFT Word? If it's
been a while, not to worry…90% of the planet uses less
than 20% of MSFT WORD's features. Success and client satisfaction
is about simply enabling faster workflows of existing process.
Tip #3: Get feedback through client workflow
The point of UI design is usability. Focus should be squarely
on client tasks they view as solving their problems. It is
not about new features. Otherwise Bill Gates would be even
richer. The feedback loops you create to sniff out essential
functional requirements must discern the cool stuff from the
absolutely necessary stuff.
Your feedback loops (e.g. User Groups, Surveys, Mockups, Client
Research, Case Studies, etc) should also help identify feature
priorities and, by definition, how you position yourself against
your competitive set.
Send mockups to real system administrators (if you are lucky)
or work with agencies that set up such usability testing (if
you are lucky and have money). Ask these users to walk through
the mockup and ask them about the tasks they had to perform.
This means asking the right questions. This means knowing
your client's workflow. That is, knowing the process by which
they add value to their company. You can't do that sitting
behind a computer screen.
Tip #4: Create Stages For UI Development
Map UI feedback through the iterative development cycles.
Solidify the UI design and then backfill the code to reflect
the emerging requirements.
Getting mockups and prototypes to key users in a timely fashion
during ever quickening development cycles is as much CRM as
it is engineering. Tunneling into the alpha codewith clients
means you better have a focused agenda with clear and specific
questions that when answered determine the success or failure
of that iteration.
A good generic approach:
Stage
1: The questions to be answered should have a
wide scope: Will it work? Is the workflow right? Are
there enough buttons? Is there too much scrolling?
Stage 2: Gauge the users' first exposure to
the new UI: Can they accomplish their core tasks with
the functionality of this version?
Stage 3: Addressing product usability challenges:
Are there enough options and settings? Is there enough
control over these configuration functions? Do the
implied and explicit workflows add value to their
core tasks? Does the system enable new and better
ways of doing what they do now?
Stage 4: Align the look and feel: Does the
software look complete? Are UI elements, e.g. fonts,
colors, descriptive text and layout consistent and
easy to follow?
Your dev team will need several iterations after getting
to UI/code freeze for QA so finish these stages as
quickly as you can before the scheduled release.
|
Tip
#5: Develop Prototype Demos With Refreshed Data
Clear UI development requires maximum feedback. If you have
early builds, e.g. testable software instances, make sure
your core internal user group can get to it 24/7. QA servers
going up and down is a trivial issue when giving everybody
a chance to get used to how the product looks and feels. NOTE:
Keep your technical writer (if you are lucky enough to have
one) in the loop.
Tip #6: Protect and Defend User-Driven Feature Sets
Scope creep because it's cool is a hazard. Minimize what you
add to the product as it affects documentation, support, and
the code base. Every new widget requires a new UI design effort.
Validation with your core user groups and close client users
can test these options to ascertain their value. It can also
sometimes lead to new enhancements you never thought of…e.g.
a self-service, department-based Calendar for scheduling time-off
requests came out of a request for an appropriate subject
line in a messaging email, e.g. FMLA, Sick Leave, etc. Turned
out this cool idea solves a major headache for HR.
Tip #7: Less Is More. Fewer Features Done Well Is Always
Best
Avoid putting every possible option into the UI. Don't confuse
what is possible with what is needed. You need to balance
client requests with ease of use. For product managers it
becomes a “line in the sand” moment. Stick to your
guns and validate new functionality. For UI design, as with
true elegance, less is always more. And always keep in mind
workflow, workflow, workflow. If you are not minimizing the
steps to get your client's work done, you are not designing
a good UI.
Tip #8: Build Context Into The UI
The “Home” page of any ASP-based work-related software
should help the User decide what workflow they wish to employ
next. Exception reporting is an especially powerful way to
guide Users. A simple visual of actions requiring their attention
is always a great way to point Users in the right direction.
Think “dashboards” of key measurements that are
visually indicative of exceptions, e.g. I use Red/Yellow/Green
indicators of compliance in the automotive compliance software
space…duh.
This decision support approach to UI design helps users derive
their sense of location/context from the UI. This may not
be possible at other points in the workflow UI development
has built, but on opening the application, always provide
the User some obvious form of exception report.
Tip #9: Watch The User's Workflow And Don't Comment
Validate your UI design by observation. Think Jane Goodall
with her chimps or Diane Fossy and her gorillas in the mist.
Bottom line: Do not interfere with their workflow. You can't
be there to hold their hand so the UI has got to do it. In
this way you will see what functions frustrate them and by
extension see the design flaws that must be addressed to facilitate
their workflow.
Tip #10: There Is No Such Thing As A “Simple Fix”
The knee-jerk reaction to User frustration sometimes involves
pretty new colors, additional verbiage or a “hot-fix”
software update to “production.” If a User is having
an issue with certain functionality or a feature requires
too much in-line instruction, re-assess the functionality
to determine if it is the right way to present the information
or functionality.
“Good, fast or cheap…pick two,” is a classic
refrain among developers and product managers alike. Depending
on your situation and timeline it is OK to have the agonizing
reappraisal on how to present information to the User. You
can't assume that a simple fix is the best course of action.
Tip #11: UI Design Is About “Kaizen” - Japanese
For Continuous Improvement
Spend the money to be consistent. Your Users will never know
how much they appreciate consistency until you give them an
inconsistent UI. Stick with their workflows. As they evolve
and change, your UI needs to evolve and change to accommodate
them. Keep your core internal team close but your core trusted
user base even closer. The effort to kaizen the heck out of
your UI leads to higher barriers to entry. Ask Intuit.
Tip #12: Manage And Really Use Your User Group
A manageable User Group is about 10-12 people, but within
that set there is usually a hard core group you can touch
at a moments notice of about 3 to 5. They are your “go
to” crew. Show them the stuff you wouldn't show your
mother, e.g. prototypes, storyboards, powerpoints, etc. Seriously,
the 10-12 should be made up of active users to vocal users
(aka: high maintenance clients), and cut across the spectrum
of companies you're trying to attract. Get a range, from new
users to seasoned users. This is the best way to gather input
with respect to new features and to gather new requirements
for future releases.
Tip #13: Make The User Group An Extension Of The Development
Team
Give your User Groups a say in the future of “their”
software. Let them see prototypes well in advance of the release.
If you have the ability, give them tracking numbers for the
feature they suggest so they can track its progress through
the development process. Make them feel special by treating
them as exclusive, valuable members of team. They help you
finds diamonds in the rough. Treat them that way.
Tip #14: Mind-Meld With Your User
Live, breath and really identify with your user. Know their
workflows like they were your own, because at the end of the
day they are…
Avoid the assumption that your development team is made up
of intuitive programmers. They are not. Only your Users know
what they want and it's your job to pull it out of them, to
share with your developers and UI Designers.
Tip #15: Get A Trusted 3rd Party To Do The UI
This avoids much of the battle with development, for control
over the UI design. Get folks who are SMEs as to colors, application
interface style (e.g. what your customer base expects) and
the look and feel (beauty & simplicity). They will not
only implement your hard earned features but also make a better
User experience.
Tip #16: Make The UI Designer Part Of The Dev Team
As with hard core Users, keep the UI designer near and dear
to your heart. They will be a determining factor in the success
of your product. Make sure the designer gets a drop of every
software iteration. Give them anytime access to the QA server.
Set up periodic meetings to review their work with the dev
team. Buy them donuts and coffee. Make them a part of your
team. They bring objectivity to UI design. This is valuable.
Garner it.
Tip #17: It Is About Workflow, Workflow, Workflow
Don't let cool technology get in the way of user friendly
functionality. Is the workflow manifest in the UI? Keep in
mind most Users of business software are making their living
with it. Therefore, they just want it to work quickly and
every time they log on. If it becomes a hassle for them to
use, they will complain. Eventually, the economic buyer will
act on their complaints, usually around the time your license
is up for renewal. Make the technology easy to navigate and
understand. Make instructions clear and step by step. Usage
stats will tell this tale. Keep an eye on those. And don't
mind the gnashing of teeth coming from engineering. Their
world is about building functionality. UI Design is about
improving workflow.
Tip #18: The UI Advocate
If you have a product manager you already have your UI advocate.
He/She will need the very cool ability to interpret what engineers
are saying, what users are saying, and what the UI people
are saying simultaneously, and come out the other end of this
process sane. You will need someone who can walk the talk
and document the outcomes of design team meetings, with input
from development and users. Good luck with that. You will
need it.
Article
contributed by James E. Lawrence, VP, Product Manager, Compli
- jim@compli.com
