First week “start-up insights”

After successfully wrapping up my first week at a software start-up, I wanted to briefly reflect and share some insights gained while diving into the fire and making some progress as a new designer on this small but passionate team. 

** Start with the product, to understand the customer and the business: The product is the central tangible embodiment of various aspects of the company like the brand, technology, value prop, founders’ vision and philosophy, etc. As Jony Ive said in a recent TIME magazine interview, you’ve got to deeply understand the product’s purpose and construction to design well for it. And the product is that gateway to the path of understanding the customer (needs & goals) and the business (revenue model, roadmap and strategy). Also, as a device to help mitigate the tremendous “fire hydrant” flow of information, the “Product / Customer / Business” model keeps your focus on what is most important, helping to filter / triage data streams accordingly, so you can preserve your sanity too ;-) 
 
** The product is a system, so don’t chase Band-Aids: It’s important to realize that any product has multiple parts that coalesce into a “customer experience” that the intended target needs to engage with at various levels. All those pieces simply must come together in a cohesive, coordinated, disciplined, consistent manner particularly if there’s a website, email, desktop app, and other components across platforms and devices. Indeed, the product is a system of elements at the front-end UI level, as well as the back-end data services level. Chasing isolated Band-Aid improvements for immediate releases only perpetuates a vicious cycle of broken UX rife with inconsistency, and doesn’t support a systematic approach of defining a language and patternized model. 
 
** “Design is code”: This phrase came up the other day over lunch, which I think nicely captures the spirit of the symbiotic relationship between engineers and designers working together. Indeed, a well-formed, good product cannot exist without one or the other—gotta have both! The design informs the code to be delivered to users, and thus their experience and outcome of that. Also this highlights the partnership aspect of being part of a team that respects and values design as integral, not simply a hasty after-thought.

Yup, what Jony said

In a recent interview with TIME magazine, Apple’s legendary head of design Jony Ive was quoted as saying this, when it comes to designing a new product: 

Objects and their manufacture are inseparable. You understand a product if you understand how it’s made. I want to know what things are for, how they work, what they can or should be made of, before I even begin to think what they should look like.

Exactly. This statement wholly captures my design attitude as I insert myself into a start-up context as the main, and—for now—solo designer. For me to be a successful designer impacting the product (a web-based SaaS application for IT Admins) in a significant way, I can’t simply jump to visual styles to beautify—as tempting as it may be! I’ve got to fundamentally understand the product purpose (why it exists and for whom it provides value), the product mechanics (how it all works, as a Big Data analytics tool for IT Datacenters) which means diving into some fairly demanding technical concepts around datacenter operations, and the product manufacture—indeed, how it all gets coded up! What is the actual code construction process in terms of tools used and frameworks applied, for the front-end (like angular.js or CSS3) and back-end (leveraging AWS servers). The more complete my understanding of the product, then the more effective and influential I can be as a designer shaping a bonafide experience that respects the product’s essence. And then…I can amplify the product to the next level via beautiful and rigorous design. Designing a software experience implies knowing how it’s constructed, to have maximum impact.

Cramming for the new job!

As I prepare for my new UX Director role with the big data analytics start-up Cloud Physics, there is a range of categories of knowledge I’ve been rapidly absorbing (i.e., cramming ;-) so I can hit the ground… umm, sprinting, as it is!

Below is is a brief summary of what I’ve been refreshing myself on over the past several days:

** Customer-oriented metrics: Being a data-driven start-up, I need to gain maximum understanding of key concepts around customer engagement, adoption, retention and satisfaction (Google’s HEART framework with GSM, in particular), including NPS and other useful metrics for driving not just design decisions but also supporting business goals. Keying up for A/B testing is a necessary part of this, irrespective of my own personal disliking ;-) 

** Business model canvas: Oosterwalder and team have created the ultimate tool for applying designerly approaches to shaping a business. The critical elements that comprise that business and how they interact with each other—that’s something to constantly keep in my mind as we evolve the business and product offerings this year.

** Visual production & UI prototyping tools: There is simply no way around this, I’ve got to roll-up my sleeves and dive heartily into design production, at least initially, before my team is formed. Gotta deliver immediate results to help establish credibility and value, right? And there is no shortage of tools, particularly non-Adobe tools that are free or inexpensive ;-) Being cost-efficient while “satisficing” is a virtue in a start-up context.

** Lean & Agile processes: These methodologies and philosophies have become a simple fact of life for any start-up today, so I’ve got to understand the pitfalls and opportunities inherent to them, as well as anticipate ways to creatively blend them with design-led processes. 

** Big Data concepts: Well, of course! After spending four years dabbling in cloud and virtualization tech, along with multi-touch mobile UX, it’s now time to shift gears, and dive into the concepts and terms that constitute “big data”, beyond buzzwords. How do velocity, variety, volume, and veracity (the Four Vs) impact the data’s expression and interaction within an interface? Hmm!

Finally, I am casually revisiting various favorite design books that have become my “Go to” resource stack, including Microinteractions, Envisioning Information, Designing Visual Interfaces, and so forth…to help with priming the mind for design leadership!

Disrupting the dream job

For just over 4+ years I had arguably what some may consider to be the “dream job” in software design: serving in a largely self-defined Principal level role for a revolutionary team ushering “Design Thinking” into a 25 year old enterprise technology firm, Citrix—with 100% executive support from our CEO and SVP of Customer Experience. I worked on initiatives that combined my talent and energy: Driving visionary concepts, leading design evangelism, delivering innovation with the Citrix Labs team, coaching startups at the Startup Accelerator, and running a successful design speakers’ series, plus countless other activities that were fun, rewarding, and impactful. In a rare situation where I helped shaped design vision and culture—with executive visibility and trust— I also learned a great deal about what it means to foster a corporate design team’s success (witnessing its rapid growth to over 120 people!), and what it means to be a design leader (not for the faint of heart!)…with all the inherent challenges, frustrations, and anxieties ;-) It has been an amazing journey.

And in the end, I did everything I sought out to do…and more, with opportunities I never imagined possible. I can say with sincere gratitude and profound awe: “Mission Accomplished”.

So, what’s next? How does one transcend such a uniquely compelling situation? What comes after the “dream job”? 

Now, it’s time to disrupt. In tech circles, this is has become a trite buzzword implying some game-changing invention that radically alters convention (usually along with some wild-eyed multi-billion dollar valuation ;-) However, for a designer— a fundamentally creative individual, who constantly evolves, seeks stimulus for personal and professional growth— once awhile you need to pursue that risky, uncommon opportunity, a catalytic event to shift your whole perspective and approach, taking things to the next level. To learn something completely different and push your own limits. Sometimes, you just need to disrupt yourself. 

And what better way to do that than by joining an exciting 20+ person start-up called Cloud Physics, as their Director of UX, charged with bringing beauty & soul to “Big Data” analytics? :-) While I’ve been in Silicon Valley for 12+ years, to the surprise of many I’ve actually never worked at a start-up before (ironically, perhaps). So let’s take a leap—into a wholly new role, company, and environment with a compelling focus and critical impact upon design strategy & vision. There is no textbook or class syllabus for something like this—improvisation will be key! I’ll be taking a different approach from “big corporate” Customer Experience, emphasizing a Lean, Navy SEAL, craftsperson approach to delivering design excellence. I might even learn to code, just a little bit ;-) It’s both exciting and daunting, with plenty of worthy challenges ahead. I look forward to sharing lessons and insights from “start-up land” in the coming weeks. Stay tuned!

Actually, users don’t always know…

Inherent to the design process, “the user” is regarded as the prime source of necessary, valuable, actionable information for making sensible design decisions, captured in a variety of forms, from A/B tests to in-context interviews. However, we should be careful in assuming that users have all the answers or, to put it bluntly, know what’s best. Before we appoint “the user” to the holy pedestal of infallibility, it’s worth remembering the following:

* Users (i.e., humans ;-) are contradictory, messy, emotional beings with hidden motives and desires, and often have difficulty articulating them accurately. They may have an instinctive sense for something being “not quite right” or “just spot on”, but often have a very hard time expressing it in a way that product decision-makers can act on it effectively. This includes the lack of proper language to convey it well (“Make the button red and flashing” is usually code for “this button is very important”, not actually put burning flames on it.)

* Users usually only know their current situation—thus, can helpfully itemize all the perceived problems from their POV. However, they may not have a sense for how to improve things in a significantly useful or novel way. that “connects the dots”.  This requires stepping outside of themselves to spot opportunities they might be blind to.

* Users are quite good at local tweaking, optimization of their specific tasks against known or perceived problems, of some tangible factor. But not necessarily global, architectural, flow-level issues of coherence, integration, aggregation, of the entire ecosystem, since many rarely experience or see the total system. 

* Users aren’t empowered to make tradeoffs and compromises impacting the final product or service delivery—which might effect other users beyond themselves! The product team has that responsibility. Users don’t need to know all the inside baseball that goes on, of course, but designers do and that necessarily impacts what’s possible, viable, feasible just as much as what the user needs.

Ultimately, users are not designers. I know it’s obvious, but it’s true and often has to be stated. That’s why well-trained and educated designers are hired, for their ability to interpret and transfer user-oriented findings into strategic and tactical, well-considered, decisions around affordances, semantics, task flow, visual style, and functional value. Users are essential to that process but not sole bearer of all the answers, for a good reason!