I'm a software developer, and I'm going onto a project now that involves implementing a website using ASP.NET (3.5 / 2008, using the Web Client Software Factory). I've been tasked at creating a UI / UX Design Document for the project, however I don't really know where to start.
I've been on one project in 3 years where there was a formal UI design document, which included layout and style guidelines/rules (e.g. the application has a header, navigation, etc., links must be colour A, buttons for positive actions must be on the right, etc. etc.). It was pretty useful in hindsight, I appreciated that someone went into that much effort too - even defining the CSS classes in the document. However, the doc was based on an existing application and conformed to the business' overall corporate identity.
The current project is a new project, which at the moment doesn't have clearly defined requirements (yes, I know... how do you design when there aren't many requirements... I digress). It is hard to know what functionality exactly will be needed. There are two different user types / personas, but no formal research will be performed on them for this document. Also, I'm not sure of the corporate identity, apart from that the business has some rules regarding use of their logo, which I'll only get further clarification on in a few days time.
So I'm slightly in the dark, throwing paint at a canvas, hoping I get a pretty picture at the end (if only I were Jackson Pollock).
What would you include in this document? It is aimed at the business (the client), as well as the developers. I can think of only the below:
Layout - header, footer, content, navigation
Styles - colour palette and styles of the different expected components
User Interactions - when a user performs an action and must wait they are notified by a modal dialog, validation is done using AJAX, navigation should be contextual, tasks should be performed with a minimum amount of clicking / navigation, etc. etc.
Has anyone got any experience in creating such a document, or any known, tried and tested process for UI design?
Thanks,
James
There' all sorts of elements that could be included in such a set of documentation:
visual style guidelines (colors, typefaces, sizes, icons, etc)
branding guidelines (corporate logos, colors, messaging, etc.)
copyrighting style guide (terminology, proper messaging, proper voice, etc.)
persona/demographic targetting
page layout guidelines
CSS guidelines/standards
JS guidelines/standards
use cases
accessibility issues
usability issues
example implementations
IA path flows
Wireframe components
etc.
I'd pick up this book if you can to give you a start on thinking about this:
http://www.amazon.com/Web-Anatomy-Interaction-Frameworks-ebook/dp/B002ZY5FCW/ref=sr_1_2?ie=UTF8&s=books&qid=1262983955&sr=8-2
Along with all the other obvious components of your planning document, it would be a good idea to sketch portions of the UI along with an accompanying narrative of the specific use cases illustrated.
I've had issues in the past when attempting to communicate UI ideas. It is often useful to make sketches of dialog boxes and sequences of actions. If those sketches look too "real", then there is a tendency for them to become the spec for the final product.
To mitigate this, I've been playing with Balsamiq Mockups. It has the nice property that it is an editable back of a napkin, and deliberately renders all objects and screen layouts with a hand-drawn feel. I like the results I've achieved with it for small, internal projects. I haven't (yet) had the chance to use it for a large project with many external stakeholders.
The Wikipedia article for Human Interface Guidlines has some great links that I was going to suggest. Some of them may have far more information than you require, but they should give you a good idea as to what types of things you should add.
I have always found Apple's guidelines very complete and useful, but they are definitely very complete and require a lot of reading.
UX documentation is a critical part of the UX design procedure. It functions as a connection, providing context to the product’s lifespan from the initial concept to the present iteration.
Good UX documentation is straightforward yet lean. It should be favorably attentive, actionable, and purposeful. UX documentation is a functional document of a product’s journey from the beginning to the current release. This documentation is important for several reasons:
Organizational memory
Onboarding & handovers
Single source of truth
Fosters better communication & collaboration
A valuable R&D and IP
Related
If a question seeking product recommendations is not deemed 'right', please feel free to lock/delete this post. I will seek other avenues.
The presentation layer of enterprise applications has hardly ever been my focus area. However now, I am required to look for a development platform that allows quick and easy development of dashboards with widgets. Where, development is no more than drag-drop and few clickys here and there. This is because the audience is more of business oriented folks than development staff.
After much browsing around, I think, I have short-listed the requirements of a development platform suitable for us.
Custom display elements. I should be able to import display elements (line chart, bar graph, etc.) or develop on my own.
Event-based refresh. All the display elements should have an option to refresh itself based on events than on a refresh time period.
Responsive. The display elements should render correctly on different browsers on devices of different aspect ratio e.g. laptop, desktop, 42" LED TV, etc.
Internationalization support. All display text and locale elements (date, money, etc.) should be rendered via a 'bundle' or at least be programmable for me.
Hand-held friendly. The platform maybe provides a SDK that allows handling of device gestures for rendering display. For example, pinch to zoom, swipe, etc.
Ideally, an open source product backed by commercial support would be great.
Most options that I have seen, do not have an easy drag-drop feature. For example, d3.js has some really amazing visualizations but, probably requires non-trivial development effort. I checked out Freeboard too, but, I am not sure if it can extend to custom data sources and widgets. Splunk looks good but I am not sure how extensible it is.
So, what are your suggestions?
I would highly recommend Splunk for your case. I have been working with it for quite a while now and have seen numerous capabilities. It is not true that it is not responsive; most companies demonstrate Splunk dashboards on wide screens, projectors, mobile phones, etc.
Using custom display elements couldn't be easier. There is a variety of options of charts,graphs,stats tables and others,plus you can work with various programming language from simple xml and html to javascript (d3 libraries are supported for D3 visualizations) for more complex applications. You can add drilldowns to your panels, time pickers, search boxes, all by using its GUI interface.
You can easily configure it to "auto-run" when new events are available by choosing one of the real time options , e.g. 1-minute-window, 5-minute-window,etc.
You will be impressed how easy is to "form" your data, as Splunk recognises and extracts timestamps and time zone data automatically (of course you can apply your own settings in any case). It is also capable of recognising different data sources (like json, syslog, database logs, etc) providing the proper configurations for line breaking, fields extractions, and other options, allowing regex replacement too.
Imho it is the easiest and most robust way to visualise your data quickly allowing a lot of space for customizations.
I have been playing around with php-gtk recently and in the past I have experimented with Java to make GUI 'hello world' apps.
However both these types of applications have had a bit of a clunky (almost childish) look and feel to them. I cannot deny that they are handy for making apps for in-house use (and I totally respect the amount of community effort that goes into these projects). But I would not necessarily be proud to sell it as a commercial application with a price tag of, say, £450 or £1,000.
If I wanted to make an application that had the look and feel of, say, Firefox for Windows, or Adobe xyz, what GUI/language should I use?
Is the 'professional sheen' or smart look and feel 100% down to the designers or is it the case that, no matter how good a designer is, picking the right GUI framework is essential to get that look?
There are a few aspects to having a polished UX for a piece of software.
Using the most native framework for the platform. Win32/WPF for Windows, Cocoa for Mac etc.
Application's visual artefacts are coherent - this includes images, graphics, toolbar icons etc.
Following the platforms guidelines and best practices.
It's overlapping a bit with Igor's reply, but here's my take:
Native Control Look - UI controls today have a rather complex appearance. There are many visual cues we instinctively derive from them, and even if it's a white rectangle with some frame, with the wong shadow it looks strangely out of place. A context menu often doesn't just open today, it slides in from some direction, or fades in.
Native Control Behavior - Even more complex than UI, there's a lot of detail to behavior: different context menus depending on click position, different "hot" areas when selecting or dragging items, keyboard shortcuts, etc.
Attention to detail - There's a lot of consistent UI behavior to discover on any platform. Just the way arrow keys work in a tree control WRT selecting, opening and closing nodes.
Just look at Windows: Most non-native toolkits get the basic keyboard navigation wrong - Arrow keys, Home, End, PgUp and PgDown, behavior modified with Ctrl, extending selection with Shift gives up to 32 behaviors. Copy & Paste is traditionally with Ctrl+C/Ctrl+X/Ctrl+V and Shift+INS,Shift+DEL, and missing. Mouse double click often selects a word, mouse triple click sometimes a sentence, line or paragraph.
Response time and Muscle Memory - There are, basically, two UI operation modes:
act-look loop, where you wait for the response before deciding the next step,
playback from muscle memory, which is much faster and requires less mental processing ressources.
There are, however, two requirements for that: response must be uniform and "instant", and the next action must be registered correctly immediately (at least within 10 ms)
Often enough, with non-native toolkits, this gets hard by the response lagging behind one or two actions (the mind locks on the discrepancy), and by toolkits that take 50ms or more to show a menu, in which time a click isn't registered as intended.
A polished UI takes long to get right - A good control library can solve most of the per-control issues, but there's some final 10% taking 90% of the time, and you have control interactions. You have to try different approaches, you have to expect users with FPS-trained reflexes, you have to try all kinds of workflows.
Cross-Platform toolkits can't get it perfectly right - they are stuck between a rock and a hard place: They can opt for internal consistency independent of the platform, or being consistent with platform they currently run on. To get it right, the latter often requires platform-dependent code in the calling code, the actual thing you are trying to avoid.
Always try to use the GUI framework that's used by your desktop environment. .NET's libraries are probably the best for creating Windows apps. GTK+ is always the best on GNOME, while Qt works well on KDE - even though all three work on each other's systems, their visual appeal decreases with their lack of visual integration.
The GUI API/language used is utterly irrelevant to UI design, although some APIs make it easier or fasterto implement.
Good UI is about:
Good graphic design/artwork (visual balance and symmetry, complementary colours, visually 'pleasing' shapes and layouts, visual consistency within your app and with the other apps around it - consistent positioning, sizes, gaps, colours, etc)
Understanding the user's workflows and making what they want to do easy and intuitive. This often means implementing 3 or 4 ways of achieving the same action (e.g. "Copy and paste" can usually be achieved by: main-menu->copy/paste, context-menu->copy/paste, ctrl+c/v, button:copy/paste, drag-and-drop)
Keeping everything simple. Remove as much as possible to cut the UI back to just what the user needs and no more.
Being intuitive and not surprising the user. Controls should look like the controls the user knows, work like the controls the user knows, and be located in the places a user expects given their previous experience with the computer.
Following the conventions (position OK/Cancel buttons in the standard locations, use the OS-defined colours for highlighting selected objects etc)
To get this, you need to look at lots of "good" applications and dissect what makes them good. Get a good artist/graphic designer to draw you good icons etc. And spend a lot of time thinking about the user's workflows.
Make sure you separate the business logic from the UI - this will allow you to re-skin the app easily to improve the UI. And usually the data the program needs is not related to the way the user needs to use the application - don't be tempted to just expose your x,y,z variables in editable fields! UI is the layer that hides your implementation and makes it usable!
I don't care for the way Java application GUIs tend to look using the usual toolkits. If you like the way Firefox looks, you might look into XUL and the GUI framework shared by most Mozilla applications. Komodo Editor/IDE use the same tools (along with several other applications). GTK is very powerful, and I really doubt it is what is preventing your applications from having that professional sheen. Keep exploring it's features, and rethinking the best way to display your components, and I'm sure you'll stumble upon an arrangement that feels better.
On the other hand, it isn't all about the toolkit. Good interface design is an art, and interfaces like Firefox have evolved through endless amounts of feedback. The best thing to do is talk to users and find out what will make them more comfortable using your application. I've found that software tends to look good when it is also functional.
I would recommend spending a lot of time in software that you find pleasant to use. Make notes of the way things are done, and look for commonalities among interface elements. Most software sticks to a pretty common set of principles that make using the software easier, and the more you explore the software you find appealing, the sooner patterns will start to emerge.
Good luck!
I work in a small and young team of developers and we have problems that we are not sure how to solve.
On previous projects every developer have been working on tasks that were based on use cases. So, upon setting the system architecture, each team member worked on user interface and business logic of tasks assigned to him.
This kind of organization gave us the problems with UI. Each developer had his own logic about how UI should look like, where buttons should be, etc etc... and even if we've had one css designer a lot of refactoring had to be done in order to make web site to look compactly.
How do you deal with this issue?
Do you split tasks based on layer, not on whole use case?
Do you use some technical solution to achieve this or is it just written standard that every developer need to follow?
Thanks
Everyone has their own style and it would be difficult and a waste of time to define a standard that would get everyone to draw the UI in a consistent manner. Instead, elect your best UI designer to do what he does best and design the UI for the whole system. Funneling all UI changes through the designer would be difficult so just let your developers "mess it up" as they implement new use cases and just have your designer clean it up before the release. It shouldn't be hard for him/her to rearrange the existing forms and bring some consistency back to the UI.
I've found this 12 Standard Screen Patterns article very useful.
A solution might be to create sketches of all screens of your application, have them reviewed by an ergonomy-expert to correct the biggest mistakes, and, only then, give them to your developpers.
This way, they would know how the screens they are developping should look like -- there will still be a couple of differences in the end, but those should not be "big differences", and should be eaiser to fix.
And this would mean not each developper has to imagine what the perfect screen would look like : each one of those would be coherent with the others.
Adopt the tried and tested MVC system, let the view be decoupled from the business logic. Then ask a UI designer to produce sketches and work to that. UI's are something best done top-down from my experience. The user gets an overall view before being presented with all the details, defining and capturing this hierarchy makes good UI's. Coding of business logic is done as you mentioned on a use-case basis, mostly bottom-up and this is where the code falls out of sync with the UI.
Designate one person (preferably someone with graphic design experience, even if they're not really a programmer) and give them the authority to make cosmetic changes to all forms, pages and controls at any time, and have them be responsible for the overall look and feel of the application.
As far as metrics go, keep track of how much time this one person has to spend "fixing" each programmer's work, and make sure the programmers are aware of these numbers. The idea is to encourage them to make their stuff look like it should from the beginning, but also not to do weird things based on what they think stuff should look like. I've had to spend more time undoing my coworkers' bizarre design choices than anything else.
Don't be afraid to have outside sources review the design work of each programmer. It's very common for programmers to 1) produce horrible-looking UIs, and 2) believe the UIs look fantastic. You should do what the Army does with boot camp: break them down completely right from the start, so that you can build them back up again the right way.
Part of the problem with creating your own written standard is that while well meaning, there could be mistakes or better ways to do things than what's been standardized. For example, where I work, the standardized cancel button does nothing when you click on it (it's been wired to Reset).
Instead, I recommend choosing existing standards, such as The Macintosh Human Interface Guidelines or Windows User Experience Interaction Guidelines. Even if the standard is wrong, it's rarely profitable to deviate from widely established conventions.
Then pick up some good books for the developers, such as "Designing Interfaces: Patterns for Effective Interaction Design". Good user interface design is partially a matter of good taste, and while not every developer will be interested in the subject, it's in your best interest to help them improve.
Next, empower your QA team to file bugs when the interface for one product is inconsistent with another. The developer can then either standardize or justify the deviation if he has a reason. We do this; it works pretty well.
Lastly, go over your existing products and get a consensus on how their interfaces should be unified. Bring in (and keep) a usability expert if you can. I've seen good ones do amazing work.
There really is no clear solution for how to deal with UI problems. There are however several approaches one can take to combat the problem of having things become too complicated:
Use cases are usually cross disciplinary in nature, thus the responsibility to get a use case done should be split between the people who can implement it properly. Programmer and designer type of people need to cooperate.
Everyone in the team needs to keep in mind seperation of concerns, i.e. things that can be seperated must be kept that way preferably as early as possible. There are so many ways to do this: e.g. apply MVC pattern in your project (which is a very wide way to put it). Presentation and logic should be seperate so that changes in one layer should not affect the other.
Someone needs to be responsible for the overall UI design so it is consistent throughout the application. Preferably someone who is both a graphic designer and has some insight in usability. UI design is something that needs to be planned along with the use cases and revised constantly as development goes on. Consistent UI is very important and developers need to be on board on it.
I've been asked to research what the best practices are when building the international version of your site.
The main question being asked of me is how we handle Chinese and Arabic.
For example, when the user selects Arabic as a language, should only text be right aligned or should our nav, logo and general layout also switch around?
When comparing to other large corporations, Apple and IBM don't change their layout but Microsoft switches almost everything around.
My good friend Google hasn't been much help so I was hoping someone here could help me out. Does anybody have answers? Some tips and/or resources?
This is a very broad topic, but you did mention that Microsoft "switches everything around," so I'll talk a little about that.
There are a few components to supporting many cultures with your application. Some of the considerations might be:
According to the W3C, internationalization refers to preparing your application for other cultures by removing hard-coded strings and making other kinds of resources, like images, localizable. This should be part of your software design/build/test process from the beginning.
Localization can be broken down into two specific areas:
Language localization is the focus of most international software. Strings and images are converted to another language and loaded dynamically using the current culture.
Cultural localization (something for which Microsoft is famous) is the practice of changing UI elements to better-fit other cultures. For example, in the US, red implies an error or unfavorable message. In other countries, this is not always the case.
For software to genuinely be cross-cultural, you need to address both types of localization. For your web site, though, it's probably sufficient to localize the language strings and images as appropriate; you probably don't have the resources to have user interaction designers working on laying out your application for different cultures.
As ever in UI design, "it depends."
In this case the things you want to check include:
What kind of users are you expecting? What technical level?
What Web experience are they used to?
What resources do you have for the localisation?
Technical users (e.g. developers) will most likely prefer the same layout on the site as other content.
For Arabic, while Web-savvy users are reasonably familar with left-to-right usage, it feels "wrong" and so your site will need to be quite compelling to make sure people stay. If you can change your layout then do.
For both Arabic and Chinese there are many customs and idioms that are quite different, especially when it comes to graphic design. Popular sites in particular look much "noisier" than is usual in the West: a site like stackoverflow.com would be very minimalist in these cultures.
Similarly be careful with things like lucky and unlucky numbers, colours with traditional associations, and suchlike. (This naturally goes everywhere: I could mention the comments we had from Northern Ireland about a very orange-branded theme that was once chosen for a site I worked on...)
What I'd recommend is that you allocate some of your translation budget to a local native-speaking UI consultant. They'd be able to give you proper advice on what bits of your site need to be localised as well as translated.
This guy has a raft of information. Beyond that, my problem is that I'm used to helping people do this via a multi-day consultation, and I'm not sure how to summarize into a post that fits here. That really isn't our business any more, so, honestly, I'm not shilling for work.
I've done plenty of programming before for CLI and the web, however recently I am getting into desktop GUI programming.
Most of the tutorials for GUI programming I found just explain the different controls you can use and leave it at that. Some of the better ones also skim over a few usability issues.
However, my problem is not with the APIs, or the theory but with my code.
How are you supposed to organise different views your application might have (e.g. a IM application has a login view, a contacts list view, a conversation view etc.).
Are these supposed to be different classes or different methods on one class?
Different panels that are hidden and revealed, or different windows altogether?
I'm hoping for answers as language agnostic as possible, but in case that's not possible, the languages/frameworks I am considering are Java/Swing or C#/WPF. However, if there's another language/framework that is significantly better for learning from, I would consider using that.
Normally each view will be a seperate class in a seperate file. The class will then most likely implement some base class like Window or Control.
As far as organization, if it's a simple app, put them in the root or in a UI folder. Or perhaps a Window folder and Controls folder.
If it's a large app with several views, than break them out into functionality, i.e. an IM folder.
I would say go with what Joshua said and as far as using different panels that are hidden and revealed, i've worked on old code and it's a nightmare to re-use (8000+ lines of Delphi 6!) so stick with different windows as much as possible!
The generally recommended overall structure of the program is the model-view-controller (MVC) type of structure. So, first off, don't make the actual data part of the views, it goes into the model. From here, since the only data in each view window is now almost entirely just layout information and what to do on an action (click, data display, etc), if these are different, they should probably be different classes. If there's some general functionality that can be factored out, you can make this a base class and inherit from it, but in the end, windows with different functionalities should be different classes.
If you are going to be using one of the mainstream IDEs it will handle some of this work for you. The default will be a different class for each form. Hidden panels and tabbed interfaces are nice features but do yourself a favor and learn the ins and outs of embedding groups of controls into form. Some frameworks allow you to directly embed one form into another. Others have special containers that can be be embedded.
The point of these is to break up your functionality so you don't wind up with a bloated form class that's difficult to wade through.
I would also spend some time looking at some of the architectural patterns for keeping your business logic separate from your UI. Check out this link for a good starting point.