Unifying and iterating user experience: part 2
This is the second part of what is an unknown number of posts about developing a cross-platform, cohesive user experience, among multiple products and technologies. Working for a startup presents a whole new set of challenges that make crafting the user experience unique.
Lesson 4: Make the rules. Then stick to them.
Rules based on a longer-term strategy can seem like a lot of time-consuming procedure and structure to apply to a technology platform driven by Agile development, and a startup in particular. The shifting needs of a new organization don't lend itself to hard and fast rules as well. But when I talk rules, I'm not talking about something typeset, printed and bound as an official doc. I am talking about some overarching principles that never give way, even if it's just in your head.
Pick some key items that you can utilize across the organization and go with it; typography, color, treatment of links, consistency of voice and visual structure. What other areas of the business are using and reinforcing these things? Some things are easy and obvious - headers, link colors, labels, components - others are more subtle, like content flow and tone of voice. Whatever it is, be open, redundant and repetitive, not just with the marketing and branding folks, but with the development team.
Developing a user experience over time is an exhaustive process, and it's easy to lose focus when you're thinking about interface improvements in your web applications. Carrying the experience across the brand can help establish a direction and strategy for the UX, and keep it in focus, even if you're undergoing iterative development on a technology.
Maintain consistency, and make it a religion.
Whether you work for a large company or you're a small shop, there never seems to be enough folks doing QA toward the user experience as a whole. Establishing some rules and giving voice to those rules through the process, will help you build an auditing system. Rad. No, really, it IS rad. This is one audit you want; you want your team checking you and questioning you. Monitoring all the nuances of good UX is a huge task. The more people you have advocating for consistency and understanding, the better your user experience will be. You will not just help keep yourself consistent in the little things (devil's in the details, right?), but the rest of the organization begins speaking the language. Just like you start geeking out about Java, everyone will get jazzed about consistent use of alerts. Get them asking questions as they see gaps in patterning.
The best feeling is when someone on the tech side questions a UX decision and you realize there's enough pattern and structure in the framework for everyone to contribute to the experience.
Lesson 5: Truly understand what a "user experience" entails.
We know the UX is more than just how things look and what things say. It's the overarching guiding principle you're defining for your audience, but it's not the main show. Rather, it's the unseen framework that shapes how the user locates what they need to find or do, how they do it, and how they move past that to the next piece.
Defining this without being limited by it is challenging for a startup; the requirements and functionality are constantly evolving. How to add this to the mix? By thinking of the experience as an organic flow, rather than a set, controlled path. Remember, defining and creating a user experience is different than defining the user interface. The interface is somewhat dependent on the technology or framework you are implementing on. The user experience, however, is moving towards a larger, separate strategy that can take the technology into account, but should also include other aspects of the business and brand outside of just the interface(s).
A startup may or may not know who its technology user is, cos sometimes there isn't an established user base yet. You're operating on a hypothesis that is constantly evolving. Defining a user experience, then, is a bit like trying to see a path through the cornfield. So much of it is intuition and educated guessing; but you should always have a sense of what you're moving towards. You are navigating your way partly by what you do know about your (future) users, and partly by understanding the environment you're in (who and what your business is).
There is a truly large chasm between UI design and a UX strategy.
Going back to the cornfield analogy - think of your user experience strategy like navigating the cornfield, and shouting directions to your users so they can follow you at a distance. You're anticipating two sets of needs; how to get them to the point where you are (level of understanding) and how to ensure they have enough information to keep moving forward.
Which makes the next lesson critical...
Lesson 6: Know your product. Be your users.
Do you really know your product? What I mean is, do you REALLY know it? Do you know what it actually does or do you just know what the marketing language says what it does? Does it deliver to who you think it does? Sometimes there's a gap between who you think you're serving and who the actual users can be. Often what you want your product to do and what it's doing now are different, especially for an emerging company or technology. Which is why it's critical to understand who your product works for and what needs you solve.
I used to be a big advocate of personas. I still am, in a way, but with a quickly evolving cross-platform technology, and a shifting organizational strategy, I've modified to viewing users within a role or set of needs. A persona can skate around the real crux of what actually makes the user unique from a business point of view (why am i here and what do i need to solve? vs. i drive a station wagon and garden on the weekend), locking you into preconceived reflections of the user based on the details assigned, that can get in the way. Make sure you understand who your user is from a needs and pain standpoint. If you want to fill out the other stuff later, then great. But get this core piece done first.
There's commonality and crossover between your users and your product. You're designing and deploying features and functionalities to either meet the needs of users, or to be the solution your user didn't know they needed. Once you know your product, and know the users it focuses towards, you can work on honing the experience strategy.
Once you've identified the gap your features fill, and have gotten to the core of what features work for which user type, then step heavily into the shoes of each of your user sets. Make sure the features you've defined for that user really solve the pain points they have.
Let me repeat that. Step heavily into the shoes of that user. Be that user. Make sure the features you've defined for that user really solve the pain points they have. This one is actually a hard lesson, since there's a lot of grey area here. You have to truly think objectively about what you're defining. It can be hard to let go, but once you nail this down, you can actually create an experience that communicates to your people in a way that's captivating and rewarding.