Advice needed: creating a new UI standard

24 Jun 2009 - 1:13pm
5 years ago
7 replies
998 reads
Brian Mila
2009

I've been tasked with creating a new UI standard for my company. I
thought it would be a great project for me, one that would allow me
to exercise my usability skills and give me the means to convince
people about the virtues of user-centered design (something lacking
here). But, nine months later, I'm wondering if I'm going to be
fired when the new standard is applied to an application, and
everything falls apart. I knew this wouldn't be easy, but I didn't
know it would be this hard. I seem to go through periods of feeling
like I know what I doing and other periods where I feel like I'm
drowning.

Right now, I'm drowning.

The standard itself seems to be moving along, the layout and control
set have been determined. The colors and icons have been settled.
But how is this going to help design all the hundreds of application
pages? How do I make sure the standard helps teams design? I have
visibility to only two projects, out of the 5 or 6 that are currently
in progress. I see the way these two do design, and it doesn't look
a new standard is going to help them design a better product. They
come to me with the usual question, "how should this screen look?"
and I respond with the usual answer "what is the user trying to
accomplish here? what information do they need to accomplish that
task?" I know that I'm just one person, and I need to create some
templates for various screens. It will help the other designers pick
a screen design that is known to work and solve the problem, and it
will maintain consistency between the dozens of web applications that
we develop. But there are so many screens, many with different needs
and different audiences, where do I begin? I've started with
something simple, grids, and began creating a library of different
styles of grids and editing paradigms and when to use which one. But
the task feels so impossibly large that I don't feel like I'm making
any progress.

I find myself asking, all the time, what is the correct next step?
What should I focus my time on? One way or another, this thing is
going live in a few months and it doesn't feel ready. I know I
don't have the skills I need to solve this problem. People who know
what they are doing typically have the answer, and usually know
multiple ways of solving the same problem. I only seem to have more
questions and very few answers. Questions like, is the standard
going to solve the minutiae of screen design details? When should we
apply a novel design, versus comglomerates of standard dropdowns and
radio buttons and input fields? How much leeway should be allowed in
designs? How far can it go before one app no longer looks like it
"belongs"? Who will be the authority to make that decision? How
do I show the benefits of user-centered design when I can't even get
the opportunity to test our applications with real users?

I don't even know what help I need. I guess I just need some
direction, hopefully from someone else who has attempted to design a
standard that will be applied to many applications, which do not all
share a common design to begin with.

Brian

Comments

24 Jun 2009 - 1:22pm
Sharon Greenfield5
2008

Pick the big five. The big five factors that standardized will help
the company the most AND showcase how good design helps.
You can't solve the worlds (or your companies) problems all in one day
(or project.)
Iterations, my friend, iterations.
Also - document. Afterwards, document how things are being affected by
the standards - then use that info in the next round of standard
constitutional amendments. ;)

On Jun 24, 2009, at 11:13 AM, Brian Mila wrote:

> I've been tasked with creating a new UI standard for my company. I
> thought it would be a great project for me, one that would allow me
> to exercise my usability skills and give me the means to convince
> people about the virtues of user-centered design (something lacking
> here). But, nine months later, I'm wondering if I'm going to be
> fired when the new standard is applied to an application, and
> everything falls apart. I knew this wouldn't be easy, but I didn't
> know it would be this hard. I seem to go through periods of feeling
> like I know what I doing and other periods where I feel like I'm
> drowning.
>
> Right now, I'm drowning.
>
> The standard itself seems to be moving along, the layout and control
> set have been determined. The colors and icons have been settled.
> But how is this going to help design all the hundreds of application
> pages? How do I make sure the standard helps teams design? I have
> visibility to only two projects, out of the 5 or 6 that are currently
> in progress. I see the way these two do design, and it doesn't look
> a new standard is going to help them design a better product. They
> come to me with the usual question, "how should this screen look?"
> and I respond with the usual answer "what is the user trying to
> accomplish here? what information do they need to accomplish that
> task?" I know that I'm just one person, and I need to create some
> templates for various screens. It will help the other designers pick
> a screen design that is known to work and solve the problem, and it
> will maintain consistency between the dozens of web applications that
> we develop. But there are so many screens, many with different needs
> and different audiences, where do I begin? I've started with
> something simple, grids, and began creating a library of different
> styles of grids and editing paradigms and when to use which one. But
> the task feels so impossibly large that I don't feel like I'm making
> any progress.
>
> I find myself asking, all the time, what is the correct next step?
> What should I focus my time on? One way or another, this thing is
> going live in a few months and it doesn't feel ready. I know I
> don't have the skills I need to solve this problem. People who know
> what they are doing typically have the answer, and usually know
> multiple ways of solving the same problem. I only seem to have more
> questions and very few answers. Questions like, is the standard
> going to solve the minutiae of screen design details? When should we
> apply a novel design, versus comglomerates of standard dropdowns and
> radio buttons and input fields? How much leeway should be allowed in
> designs? How far can it go before one app no longer looks like it
> "belongs"? Who will be the authority to make that decision? How
> do I show the benefits of user-centered design when I can't even get
> the opportunity to test our applications with real users?
>
> I don't even know what help I need. I guess I just need some
> direction, hopefully from someone else who has attempted to design a
> standard that will be applied to many applications, which do not all
> share a common design to begin with.
>
> Brian
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

24 Jun 2009 - 2:33pm
Sarah Kampman
2008

OK, first: deep breath. You sound thoughtful and competent, and I'm sure
the standard is coming along well.

You mention that the project goes live in a few months, and that you
wonder whether it will help other groups. To me, the sensible route
would be to pause what you're doing and ask your audience. Ask the folks
who will be using this standard whether it contains the details they
need, and what changes they would recommend between now and go-live. If
there's a small project just getting underway, perhaps you can apply the
new standards to that project to see where the gaps are.

Depending on what technology your development team uses, you may also
find that they can implement templates or master pages that encapsulate
many of the new UI standards. This might be a practical, good use of
time for you to help with, so that the UI Standards release isn't simply
a "thunk" of a new document, but is also a toolkit that folks can put to
use.

Regards,
Sarah Kampman

24 Jun 2009 - 8:02pm
Renato Feijó
2009

I agree with Sarah.

UI standards can be designed - rightly or wrongly - to address various needs, including those stemming from an organization's political minefield. If it's not designed with end users in mind, it will most likely sit on a shelf an be instantly forgotten.

If your standards are targeted towards developers, then a set of UI library elements that can be pulled right from the development environment and whacked into an interface, along with a few do's and dont's, could be really useful.

For other team members, having access to it from the intranet will suffice. Some senior managers may require a coffee table book (usually to beat people in the head with it).

Whatever that is, I'd focus in identifying situations where the answers to the "what is the user trying to accomplish here?" question are similar and develop common page types and/or design patterns that better address those problems. An example of common page type is a search results page. How would this type of page look like across all of your organization's apps? What kind of additional or alternative patterns could be used there to address minor variations in workflow and enhance the interface?

You need to think workflow to address flexibility. As your organizational goals evolve and change, so do your applications. Your doc will therefore need to be constantly reviewed and updated to remain relevant (the cost of which is rarely accounted for in most organizations). You can't predict what's going to happen in the next project; what you can probably tell however is more or less how your new or existing business processes are likely to unfold. Take this perspective as your starting point and remain at this level of abstraction to avoid getting entangled with irrelevant detail.

Don't forget to address error messages and copyrighting and always check your designs against valid and relevant design principles. An accompanying Visual Style Guide may or may not be useful (but I'd most certainly split it into two documents for maintenance and audience purposes).

Good luck,
Renato Feijo

24 Jun 2009 - 11:08pm
DampeS8N
2008

The good news is: Even a terrible design standard will likely be
better than 6 completely different designs which all get some things
right and everything else wrong.

The core of your job does itself by being a job. So don't worry too
much. Provided you aren't a moron and you know -something- about
IxD, you almost certainly will have a positive effect.

Look at MS Office. Once they unified their abortional interfaces into
one suite with one horrific design, it became a lot more usable.
Suffering through learning word was at least partially transferable
to Power Point or Access. (dry heave)

It is hard to learn bad interfaces, and hard to use them when you
have learned them. But a unified design for your various apps will
make that first part not a problem once you learn one app. And if you
have at least addressed some of the rest of the bad design choices
people make, you've won.

You've won by trying! So pat yourself on the back and go take a nap.

Will

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=43155

24 Jun 2009 - 4:30pm
Anonymous

I'm curious how you developed the standards to begin with. Often, its very
helpful, as you create and evolve a design system, to test out your various
solutions in the real-world context.

Some things that have helped my team are:
1. Have a regular meeting (and perhaps a committee of representatives from
the various stakeholder teams) to meet and discuss proposed
solutions/standards.
2. Make sure the rationale behind decisions is discussed and documented
3. Design with principles and a point of view - document and circulate
3. Create stencils (could be photoshop files) of the various pieces, so its
easy for teams to use them
4. Create sample pages/flows for teams to refer to
5. Hold office hours for teams to come and discuss their solutions

--
regards,
Dorelle

D O R E L V I S
Dorelle Rabinowitz
www.dorelvis.com
Watch out, you might get what you're after

24 Jun 2009 - 5:54pm
Theresa Neil
2009

One of the things I have done for many of our clients with large
enterprise applications is identify the key screen patterns- or key
workflow patterns- for their suite. Like master detail (screen
pattern) or data entry levels deep (workflow pattern).

Then we take a couple of the real screens (for important workflows in
a specific product) and show how they (designers, developers and PM)
can port the existing set of screens into the correct pattern using
the beautiful new style guidelines.

Even huge applications will (should) only have a dozen or so distinct
patterns. If you want some examples- email me and I'll show you a
few. theresaneil at gmail

Since you are going to work with a lot of teams and designers,
perhaps you should consider opening up the UI Standard for them to be
involved in identifying and deciding upon patterns, like Yahoo! does
with the Yahoo! Pattern Library.

Good luck!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=43155

25 Jun 2009 - 11:02am
Brian Mila
2009

Thanks everyone for the responses so far! Your suggestions and
encouragement are remarkably helpful to me.

@sarah: Thats a good idea about asking the audience. I will talk to
some designers. Also, the technology is ASP and we will be using
master pages and modules that encapsulate the layout, the header,
footer, and navigation. That will help maintain the consistency
across all projects but the actual design work will still be done
individually on each project.

@dorelle: Forming a team was the first thing I did. I formed a
working group of about 8 people across the corporation with at least
one from each office (we are split up with about 6 offices). I need
to get better about documenting our decisions. Some of them are
simply general agreement, other times there is no agreement and I
must just pick from the available proposed solutions. I also have a
list of items that I need to user test, if I can find the time... The
standards document is a web document that I maintain, and is
accessible from the intranet. I also plan on creating a pdf version
when its finished.

@theresa: I'd like to get there, but there are many more than a
dozen patterns I think. We currently have 3 distinct standards in
use because our applications all originated from different companies
because our company grows through acquisitions. In addition to that,
we have a very diverse audience. We have apps for the patients, apps
for the doctors, for the payers, even administrative apps that help
setup and maintain our installations. The scope is really enormous.
Another confounding factor, is that often our clients will rip off the
header and footer, and just use a portal to show the content as part
some larger site.

@william: i agree that a unified interface is a step in the right
direction. but is a new interface really going to stop designers
from making bad design choices? There will only be a handful of users
that will ever use more than one app because they are used by
different audiences, so I cant rely on a unified interface solving
anything (other than our apps will probably demo better to some
exec).

@renato: As others have suggested, using templated screens seems to
be the way to go. And I planned on breaking it down to the element
level. I'd love to have drag-and-drop components that they
designers and developers can use, complete with code and all. But
the task seems just impossibly large. How do I determine the best
area to focus on?

Thanks again for your responses,
Brian

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=43155

Syndicate content Get the feed