So what does it take to design a successful digital product or service? Is it the brand, the chosen platform, the functionality, the choice of colors, or some
Terry Patterson's insight:
Wireframes are artifacts that helps us think through an interface design. Sometimes they get omitted from the process because they are not needed (simple projects), and sometimes they are of great value (complex projects). Either way, we are challenged to produce a great model of comprehensive design communication and with that comes the responsibility to great wireframing. This article attempts to give you a bit of guidance with that.
This article highlights what people in the user experience world already know. In short, we have to expect constant change and adapt to the new modes of delivery and user expectations. System design knowledge and confidence is a given for today's movers and shakers in this field, and learning, well, is the only constant.
I find journey maps a great exercise, especially when the experience is poorly understood at first and user research has been done to understand it. The problem I see with them (from practice) is that while it is easy to illustrate a general user journey, it is difficult to account for every user mental model and contextual behavior; therefore, it is important to understand that journey maps illustrate generalities. In my opinion, complex user journeys better be backed up by good user research.
Glad we're understanding more about what makes UX strategy what it is. The more designers understand this and explain it well (as in this article), the better organizations will also value the work that is done in user experience. In the future, the UX strategist will join the organization as a leader of integrated environments in order to serve customers in the best possible way and provide the value and ROI that is needed to stay competitive.
Of course this is a great approach, but bringing the prototype at the strategy table before strategy discussion may be too premature. Bring the prototype to the strategy table, but only when the strategy is clear (or close to) assumptions on strategy and uninformed prototyping is not productive and is simply stupid. Code prototype is ideal, but only practical when you have the right team. Visual easy entry prototypes are good enough for early stages. Nothing beats feedback on actual interactive prototypes, of course, but I have to argue that systems like Axure with written feedback features and notes are ideal for design stages. If you're prototyping with Axure and not using the interactive actions, you're not using the product correctly and might as well be using a flat and useless psd. My stand, not one method fits all, do what is best and most practical for the project at hand.