A couple of weeks ago I had a developer friend ask me why I was so interested in the database design for a product that we were talking about developing together. That was a bit eyebrow raising for me until I realized most traditional "designers" might not even talk to my friend as they would assume there was no relevant conversation to be had.
Little decisions, big consequences
I first realized the importance of database design to an experience on the web a few years ago when interacting with my favorite nutritional supplement company. While I love their products, I was shocked to discover that they did not require and store (and still do not to this day) first names in their database, nor did they separate out and enable you to send your orders to a different shipping address.
This creates enormous amounts of little, prickly problems. My mom and I both have accounts - same last name, different first names. That was fun until they had usernames that made the accounts unique. She also sometimes ships me products - and this then alters her actual database record - every single time. It then has to be updated manually the next time she orders, every single time.
Be courageous - ask, discover, collaborate, integrate
Perhaps it is more peculiar to those of us that came up through the multimedia and early software years that we ended up having to deal with and learn all the parts of the business, design and engineering as we created products and services. As we're in another start-up boom time, I know many of the people coming into the industry now are experiencing the same collaborative and multiple hats training that we did.
I see that this type of work life provides a certain fearlessness of technical conversations and also asking questions of the programmers and technical folk that create the algorithms, database and middleware for the experiences we are creating. My favorite projects have been those where I get to design and develop simultaneously in tight circles. We work together to discover the best solutions using both the psychology we're aiming at and the technical expertise we have to implement and try iterations and solutions to be tested. Good geeky fun!
know thy database
There are very simple and specific reasons you should concern yourself as a UX and interaction designer with how your database and database communication is designed and functions. In mobile environments, the difference between a snappy and continuous experience of your data, particularly in list-driven applications, is hugely influenced by the push and pull dynamics with your database. Determining how to chunk and deliver the data is a task that is hugely important to the performance of mobile web and custom mobile OS apps in particular.
If you're doing cross-platform design, this is even more critical. I've never met a project that has succeeded across different platforms with a one-size fits all approach to data delivery. Desktop and tablet web experiences tend to require a much more interactive cycle of data exchange in order to appeal to a person's sense of timeliness and things happening safely and efficiently. But tablets in general cannot store as much information at one time - so how are you as the designer going to work with developers to create a strategy that fits your target devices?
Think of a Twitter app. Mostly just lists of data, right? But the difference in how each app delivers that information determines whether you experience them as "broken" or "slow" or if they retain functionality and a feeling of comfort and security even in situations where the data-stream is interrupted.
Data-less and loss use cases
And then there are the powerful use cases that are so often overlooked in database and interaction design - what is the experience like when I don't have data connectivity? Do things get stored locally until they are able to be sent? Where am I going to be storing these "drafts"? How do I best inform the person using the system that they can't get any new data right now?
It was a revelation to see how Twitter for iPhone began communicating breaks in the flow with a torn line graphic. Clicking that line provided immediate load of the missing data (if available). This was also where so many of were inspired to create pull down to get newer messages and pull up to get earlier messages interactions. These are at their core, solutions for database access interruptions peculiar to both the mobile and web in these largely data-driven applications.
Most Twitter apps also retain a fairly large set of on-board data that you can still peruse even if you don't have connectivity. Obviously you can't interact further, but there's something rather appealing to a data-driven app that can retain SOME functionality even when there is no network connectivity.
We can do better
Earlier in this post I spoke of a small company who obviously outsourced their database functionality and development. Even after I interacted with the company, as I really love their products, and wrote several emails to their developers - no changes were made. This just points out how important it is that we educate ourselves as designers on the details of how the shadowy and elusive "backend" works.
I'll keep this a bit shorter today, but other questions that are relevant to the experience are what events cue data being saved to or pulled from the database, how often is that taking place and are there fields to hold the relevant data. If you're going for extra points, discover how the middleware (the code that communicates from the front end to the database) works for your project.
The places that a designer can learn and contribute to the design and strategy of database development are huge. So, get in there and discover all the different ways that your designs and experiences are effected by database interactions and development.