Video: Map App UI Design
Here is the video from the tech session I held at the Esri DevSummit 2013 in Palm Springs, CA.
The session teaches participants best practices for reviewing, conceptualizing, designing and building user-centered mapping applications in a competitive business environment. Methods, techniques and tools for improving the user experience and designing useful and appealing front-end interfaces will be discussed.
Top 10 Design Influencers
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:
User Needs
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.
Context
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).
Culture
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.
Business Needs
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.
Technology
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.
Market Opportunities
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.
Cost
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.
Sponsor
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.
Lifespan
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.
Compliancy
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.
T-Shirt: Trust me I’m a Designer
Here is a must-have for all design geeks out there: Trust me I'm a Designer Tee Shirt!
And believe me, it's not only a vision test, it's a test in your faith as being a designer
Btw. I'm a designer and I approve this message.
Redesigning our internal Team Site
I could have titled this post "The importance of sketching" or "Paper and pencil are still hip". The truth is, I didn't even realize about the fact that I do a lot of sketching on paper, as a matter of fact I just recovered my beautiful drawing from going into the shredder. I think the beauty of sketching on paper is that the ink just flows. Sometimes you don't even know where it will lead you when you start. It keeps you minimalistic, not too much detail can be crafted on a tiny piece of paper (at least I can't).
Once I had the draft in hands, it was just a matter of whipping the right amount of bootstrap with some custom HTML and funky JavaScript, voila, our internal team site came to life... So you could say that prototyping can be done in HTML without the need for wireframes, I still doubt that. Without at least the genius idea on paper I wouldn't be able to code as efficiently as I did.
The coding part was only the cherry on the pie, a quick logo, a menu, a hero unit, some blocks and fancy graphics, tadaaaaa. I used PHP to create a 'controller' with content being included on the fly. Yes, good old content, still working on that piece, but no worries, I got it under control
How do you design? Do you sketch/wireframe? Or straight to code?
Lifespan is an important Design Decision

Mayan mahem
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?
Especially the last question bares high risk of failure. If you rely on a JavaScript's front-end framework - like we all do - say, jQuery UI, chances are that our designs will a) be limited and b) sometime be stuck in the middle once a major redesign hits us. If the redesign happens before the end of the planned/anticipated lifespan of our app, cost and effort to upgrade might not be feasible and thus we cannot upgrade to the latest versions anymore. The End.
Scalability
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.
Lesson
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?
Highlights for Week 48/2011
- 15 Responsive CSS Frameworks Worth Considering (by Paul Andrew)
- Complexity and User Experience (by Jon Bolt)
- Origins of the Apple Human Interface
- Internet Visionary Paul Otlet - Networked Knowledge, Decades Before Google (by Meike Laaff)
- The Anatomy of an Experience Map (by Chris Risdon)
- A Complete Color Spectrum of Web Design Inspiration (by Chris Spooner)
Minimalist Web Design: How Minimal is Too Minimal? (by Delwin Campbell)






