Designing user interfaces isn't about sexy graphics, shiny buttons or slick navigation (alone).
It's about taking care of the influential factors that make or break the success of a web application or website.
It's a delicate balance of user needs and business requirements, deeply understood and carefully melted into a design that is loved by all stakeholders (the end-user included 😉 )
The sum of all the design influencers are the constraints that will box your design decisions. That's not a limitation, it's liberation!
The Design Influencers are:
Whatever it is that you are planning to build, it needs to be useful to somebody and has to solve a real-world problem. This end-user need is the reason of existence, it's the meaning life.
In which context will your users access the site? Is it through mobile devices on the road? Then a shopping cart will be less important than driving directions or store hours and screen elements need to be more prominent.
Do users typically enter your site through search? Then your landing pages need to convey who you are and what you do because users won't have seen your fancy homepage (and probably never will).
Even though cultural difference across the globe become really important if you build an international site, I rather mean business or sociological culture, i.e. if you plan on building an intranet site but the company's culture doesn't encourage to report failure or spending time helping other employees, then a forum probably isn't the right choice to offer.
While your client is ideally well informed about their end-user's needs, they also have to run a business, satisfy stakeholders, fulfill legal mandates etc. And that's when compromising your perfect usability is sometimes necessary and important.
What's the available technology? Very often the vendor or client platform of choice dictates the choice of technology, e.g. a Microsoft shop will prefer .NET and Silverlight (oh, long time I haven't mentioned Silverlight so I mention it again) or Flex.
If something isn't viable or possible today that doesn't mean it won't be in a year. So think ahead and design your site accordingly, i.e. extensible, modular, maintainable.
What I've found is that sometimes it's worth including an "upsale" item into your mockups, something that the client hasn't explicitly asked for but may open their eyes and hopefully wallets 😉 Mostly you may defer these items to a later phase but it gives everybody a long-term vision and as a side-effect supports designs that are extensible.
It's been said that anything can be done if you only have enough time and money, but the real world doesn't spin like that. Your design is constrained by a budget - and that's a good thing because it forces you to stay realistic finding the right balance between innovation and familiarity.
If the main sponsor is Esri (my current employer) I better make sure that there is a map on the interface. What sounds like a designer's nightmare is the name of the game.
How long will your design need to stand the test of time? Is it 1 year or 10? A demo doesn't need to be as polished or thought-out as a content-management system that will take over the client's communication platform. It is the classical "let's get it done" versus "let's think about this a last time". I've written a more detailed article about Lifespan as an important Design Decision.
Accessibility is a law and therefore cannot be removed from the equation. Your fancy design elements might just not be (or too expensive to be) compliant with the law. Acquire knowledge about accessibility laws (e.g. section 508 in the US), their implementation specifics and know how that translates into your design.
The lifespan of a planned application or website is an important (and often overlooked) requirements influencer. Many questions come to mind that appear to be technical in nature but have to be understood by the designer to optimize their design decisions on capabilities and known limitations of the target technology. Designs can never truly be technology agnostic and in my opinion if they are, then this fact will create gaps between design and implementation later on. So you better be aware of them.
Typical Questions to ask:
- Will the app be likely be superseded by something else within the next 6 months?
- Is another known technology catching up and soon more prominent than our current target technology?
- Do we rely on third-party tools/plugins that need to be maintained or maybe will render our application unmaintainable?
Amount for various cases where your design needs to be flexible enough to handle changes over time. These can include:
- Administration: more objects (users, items) are added over time. Does the app provide pagination? Search? How easy can they be plugged in?
- Load: processing times increase. How will the system display delays in page refreshes? Download times?
- Client requests: more functionality needs to be added. Is the design flexible enough to accommodate another button or menu item? Etc.
- i18n: multi-language support needed? Now? Later? Maybe?
- Accessibility: is it worth the effort?
- Support for MVP (minimal viable product) and incremental improvements?
In many ways the Maya calendar and it's associated 2012 phenomenon are a good example for design decisions based on lifespan. Who cared back then that after 5125 years the calendar would need to be reset (or cannot handle more combinations), like many software systems didn't take into consideration what is now known as the Y2K or Millennium bug which was caused by the practice of abbreviating a four-digit year to two digits for pure storage consideration, which nowadays in our abundance world of storage is really hard to follow. But hey, it costed an estimated remediatioin of $416.- in today's currency world-wide.
Take into consideration the lifespan of your app when designing it. Any negligence is careless design and may result in increased cost or even an unmaintainable or unusable product later on.
What are your experiences with lifespan?