Can all this be done though?I think it could be done if the right ingredients were in place, first of all you’d need to find a way to frame the proposition you’re putting forward to your consumers in terms they understand – that is, you have to convince every user out there that having a tablet/laptop in one is what they need & want. Secondly, you will need to find a way to separate your product from the herd in the retail channel because right now although the brand Microsoft and Windows are attached to the said product(s) it’s also attached to the competing brands as well (ie its over-used and saturated). Microsoft have to work their product line like Apple does, by having a separate table / shelf for their products to occupy and be distinguished from the rest. Thirdly you have to find a way to become the circuit breaker for the taxonomy of online retail, by opening up a new category “both” as if you’re going to say the product on one hand is a tablet and a laptop then you need to find a way to position the products in that light. If you position in the tablet category (like today) then your $2,000 AUD Surface top of the range model will stand out as being insanely expensive for a tablet? If you in turn occupy the Laptop then you’re $899 AUD tablet with low specs looks cheap but fails on hardware specifications – moreover you also run the risk of positioning the brand as a “cheap” solution thus potentially poisoning your own well (ie "Surface = Cheap crap" perception could easily run unmanaged). The reality is Microsoft really haven’t got a structured story here with Surface Pro, it’s what I’d call a “shotgun” approach to competing with Apple/Google. In that it appears they are just collapsing the products for the sake of compete rather than actually trying to disrupt the behaviour we humans have around mobility. The product itself isn’t a measured response, its just reactive and filled with a lot of panic around how to solve this problem. The entire thing could be handled much carefully and strategically by simply easing into the above categories with momentum behind them vs just trying to force their way into the mindset of consumers that all-in-one is the best strategy. Lastly assuming they abandon these silly ads with people jumping around clicking keyboards and actually focus on “why” someone needs to buy the product they also face a very long entrenched campaign ahead. If they are onto a winning formula and assuming that they sort their marketing talent out, then they also have to wait out the consumers who currently have laptop and tablet out which could be 1-2 years minimum. Normally this wouldn’t be an issue but keep in mind Microsoft is about to get a brand new CEO with his/her own ideas about Surface Pro and if anything Microsoft’s marketing machine has shown that they can’t handle a controlled message beyond the life of a single campaign.
- Surface as a brand will undergo a split, they will likely retreat back to forking the tablet and laptop offerings. There will likely be no technical difference between the two and price and category matching will likely influence it.
- Surface will have poor sales for the next 1-2 years and the industry will remind them off this without mercy. There is to much aggravation in the hardware space for Microsoft to occupy and they not only have to compete on Consumer sales but also Enterprise pie will decay over time as a result of losing focus. The failure in success over the 1-2 years will simply be the easy punch to the company’s kidneys.
- Surface RT will evaporate as a laptop solution. If you’re a developer today targeting ARM and you’re thinking to yourself “this is fun” then you’re currently in a small cluster. Today to target Windows 8 ARM would mean you are happy to migrate your code-base over to the new Windows SDK and it isn’t a clean migration at the best of times. Moreover you have to also ignore the lack luster ubiquity metrics that will come out alongside any and all developer relation(s) resets that have occurred in the last 5 years. If you can absorb all of that and still think ARM is the vehicle of choice – then yeah, I just don’t see any upside here.
Take the freaking call. 😳In ignoring this, they in turn let the message around what this all actually means fall into the hands of the horde, which in turn means a lot of assumptions, assertions and most importantly anti-Windows Phone fuel for the rumor mill fire(s). First reading you will take a pass at this being a case of Microsoft looking to rub their greedy hands together and go for the ye olde replenishment model. If you shift all your energy & focus onto a new release for new phones, only you can replenish your profit margins with the existing user base – as that is exactly what Apple does. After careful consideration however and you continue to read on in this saga you may stumble upon a link or two that points you to the real story in around the upgrade future(s) here, in that Microsoft will promise to give you a 8.x update.
“..Distribution of the updates may be controlled by the mobile operator or the phone manufacturer from which you purchased your phone. Update availability will also vary by country, region, and hardware capabilities...”I could sit here and go all Troll/FUD on that last comment but in reality its like kicking that sick puppy again. I will simply say this; the messaging for this got lost yet again and now Microsoft have to spend cycles trying to put this genie back in the bottle. The only real way they can do this is by giving concrete assurances & specifics in around what 8.x vs 9.x will look like, specifically what does this whole Windows “Blue” strategy likely to become? They will not do that, as that would be as if again someone in Microsoft + Wagged were actually taking a proactive stance on Public Relation(s) – Probably reading their PRIME scores upside down still. To quote Tom on my facebook thread:
“..Microsoft used to control the messaging of updates a lot better, putting the blame on carriers. Carriers didn't like this, so Microsoft removed the tables they used to supply. Some phones in the US don't even have Tango right now, let alone 7.8. Have Microsoft committed to supplying 7.8 for every existing device? No. They've remained silent consistently about 7.8 and even pushed versions with buggy live tiles without a PR strategy. This support document with life cycle information has never been published before, and yet Microsoft has not managed the message well once again. It leaves people waiting for Tango or 7.8 concerned they will be left in the dark once again. Don't defend it, ask for change…”Simply put, this isn’t a story about Windows Phone upgrade good vs bad its more about how the hell does a company like Microsoft constantly forget to sit down and write a PR Strategy that actually makes sense. If you know you are about to launch a phone, then start campaigning now and furthermore do something about the release in a more visible / visual way that covers off your talking points of concern. The fact Microsoft are constantly trying to figure out a way to pander to the carriers in order to push more units is probably a strong indicator as to why Surface Pro has failed to go outside handful of zip codes as they still haven’t figured out what “logistics” and “partnerships” really look like. Apple is also being constantly used as baseline for success/failures for Microsoft in that all too often I see “but Apple do…” stop right there, Apple firstly have a strong history of success not simply because they had first move advantage on a touch-enabled phone but they have a very tightly controlled release strategy. When Apple sit down and release a product post, its actual design/development they focus in on the important areas such as:
- “How do I get this phone to some kid in outback Australia and New York at the same time?”
- “How do I control the entire PR noise around this launch so everyone takes queues from me not bloggers”
- “How do I convince consumers to move to the next phone without them realizing I’m replenishing my market”.
- Price pressure. Clearly, the other brands are opting for the Microsoft Surface Pro approach to tablet & Windows 8 bundling with a high “laptop-centric” price tag attached. That’s fine but in reality if Microsoft wants to invoke change in the OEM channels around price and industrial design then having the beacon of example (Surface) separated ensures that these guys have to compete harder to win hearts/minds more. If Microsoft can put pressure on price models with a “lead by example” model, they can in turn regain some much lost control over this entire cluster f***k of tablet/laptop sales pipeline.
- Differentiation. Right now, the whole Surface RT in Australia is all you can buy so there is minimal confusion around what the brand “Microsoft Surface” represents. It is only after you introduce Microsoft Surface Pro into the mix that the confusion will start to fester, especially when retail chains like the one mentioned seemed to be preoccupied with price. Having a clear definitive marquee / in-store controlled visualizations of the matrix would help clear up potential buyer’s remorse going forward.Furthermore it would again encourage put pressure on other OEM providers to consider the RT route but I highly doubt that will occur given the current failings of RT today (perception and execution wise).
Discovery vs Delivery.I spent over three years travelling around Australia in every capital city visiting “developer” teams for all types of companies (enterprise, startups, government etc.). I have seen the same thing happen over and over, whereby each company swears by their agile manifesto and how important it is to maintain “agile” discipline. I also notice they cherry pick agile each time to make sure it fits in with their culture and more importantly to not take it as an absolute but more a relative approach to designing software. The part that often sticks in my craw is not the sprint cycle(s) or the sprint backlog creation. Nope, the part that I immediately notice as being the fatal flaw to why User Experience is often the sacrificial lamb in the development process is well the discovery of the said feature(s). For instance, a team will often sit down in a room with a whiteboard and then begin coming up with some stories around what they are hoping to achieve with the software. They then will likely document these stories with the usual “As a User I want the ability to do X so that I can do Y” style sentences. After that process they, would likely then unpack these at a later time into developer task(s) along with success/fail criteria (tests, definition of done blah blah)? I would guestimate that 90% of the hundreds of developer teams I have visited do pretty much the above. Furthermore, I would often be invited into some of these teams at around the last few sprints to help “make it look UXy” as if there was some way I could just “Integrate” into the team(s) development process, fix the UX problems, low impact to the code and do the aforementioned in a timely manner (Usually I say: “You don’t need a UX Architect, you need a priest as this thing is dead and all you’re after is a lot of prayers to reanimate the corpse”). Let me simply say this, as a contractor I would love nothing more than to have you do the above, especially if I am charging you per hour. I could simply tread water and extract large amount of free useless work hours knowing either outcome still does not result in a successful delivery. Ethics 101 aside, today, I am not that contractor, I am a UX Architect and I have a queue of other products waiting in line for my same attention. I do not have time to drag the timelines out so I have to instead get the above optimized. The flaw in this aforementioned process of white boarding features is the part that you first make your biggest and ultimately largest mistakes when it comes to making a software product (which is a general argument to make, but hear me out). As when you sat down to the feature, you did not document whom you are making the product for. In addition, how much time did you spend on refining the process other than the first bunch of fragmented ideas? Lastly, how do various stories influence one another? Agile is not an excuse to just deliver a project without planning and planning doesn’t mean you have to spend the bulk of your time in “waterfall” delivery purgatory either. It is probably a good point to say that if you are focused on delivery and you spent little time on discovery, well you are basically in for a lot of turbulence and “UX Tetris” in the coming sprint cycles.
Unpacking the Discovery phase.Take an existing project you are on today, now look at the User Stories you have (ignore your tasks). Now grab these stories whilst grabbing some pens & notepads. Now take some of these stories (does not matter where you start) and begin drawing a comic book of your product, that is “how would you draw an activity from the moment the user clicks on an icon to the splash screen and then to what they see first”.
Example – If I was building Outlook I’d say scene(1) is user clicks on icon, scene(2) splash screen loads, scene(3) outlook opens in default folder view, scene(4) user creates new email etc.
- How much influence did iPhone, iPad, Microsoft Office, Outlook, Windows 8, Adobe Photoshop, Adobe Illustrator, Visual Studio etc. all play in the mental model you had for the software(s) design?
- How many DataGrids and Tree controls did you “assume” existing in the UI as you drew the comic story?
- Did you draw the UI as a wireframe or just abstract shapes? (If you did wireframe, stop, rub it out and keep it abstract).
- For giggles, take the existing slice you have designed and then unpack that into tasks with forecasts attached. Record that number and cost it out in terms of effort.
- Now, for giggles again, take your team and tell them “make it simpler” that is refine the story further, squeeze it to the point where you automatically feel it is not as “Powerful” in terms of feature design.
- Once that occurs, run your costs against that.
If you mapped out Outlook comic story you would probably have imagined outlook as it is today, whereby you have the tree of folders, you click “new” and prompted the same way it does today.I think of it differently, I think that whatever behavior I invoke that triggers “new” is initiated, the entire user interface goes into “new mail mode” that is the existing chrome/HUD is screened back and all the specific requirements I have for “new email” is in front of me. To my left there is a smart way to access my contacts, especially given I’m in a large enterprise and often have issues between first/lastnames and aliases”. To my right I have a different way to create an email in that am I creating just a text email or am I creating something that I want to insert media into for all to visualize my point?. My point here is I could easily increase the development cost in order to assemble the user interface in a way that for me puts all the necessary pieces the end user will need in order to carry out the said task. Simpler doesn’t mean minimal (as that can often be misleading) it means how does one make the life of the persona simple in carrying out the task – given software is made to make our lives easier right?
UX Personas are not what you may think they are.Having redesigned the new email some may declare “..hang on, you didn’t specify the feature criteria fairly..” which is true, I did not. The next thing one needs to learn is my idea of a user and your ideas of a user are highly likely two different types. A UX Persona discovery will fix the assumption failure(s), whereby if you sit down and you unpack the word “user” to the point you exhaust your collective knowledge of that means. A UX Persona is not a story about “Jim who is 22, likes fishing and blah blah” as bottom line who gives a shit who he is or what he likes. A Persona designed like that is used for marketing purposes to help sales teams position the messaging & roles the said product will likely excite. A UX Persona typically needs to focus on two simple areas, that is what behaviors they are currently exhibiting (AS-IS) and what behaviors they should be exhibiting (TO-BE). The word “User” needs to absorb the fact that sure, a user is doing xyz today but you are in the business of innovation so you in turn need to move them to a new set of behaviors!
Eg: When Apple sat down to design the iPod touch they were not pandering to existing behaviors user(s) were exhibiting on mp3 players. They moved us all over to the touch interface and it was initially confusing but today I see five year olds queuing music & playing games.Defining a UX Persona for me is mainly about breaking their behaviors into four categories
- Influence (low to very high). Take training, mentoring, buying power, optimization etc. as categories you can help shape the low to very high score. Basically how much influence does this persona have over the adoption of your new product, the training burden required in order to use your new product and lastly the output of the product (i.e. are they the end customer for your customers customer).
- Usage (low to high). Similar to influence but now how much of the actual product are they going to be using? Specifically which modes of the product are they using (e.g. Visual Studio – Build time, Debug & Runtime). If you are writing software for both an executive assistant and their boss, then basically it is likely the assistant is going to have a higher rating then the boss depending on the scenario (vice versa).
- Form Factor. What are they using to access the product? Given tablets, smartphones, laptops etc. are all evolving technology what is the likely input of choice. Do not just isolate this to device/platforms but also are they using stylus pens, are they using modified keyboards etc.
- Environment. What is type of environment are they using the product in? Is it inside a coal mine where it is dark (i.e. white vs. black colors are a safety issue), is there many hazardous issues nearby? Is it noisy (distraction and cannot hear sounds), is it inside an office? Is it inside an operator building where your product is one of sixteen screens? Environment is really an important amount of information that gets lost in the “Story” creation. As we really need to pay attention to how much duress, the user is under in order to make their life simpler.
Example – When Silverlight was being built, the first version pretty much took the 20% path with a focus on video persona(s). As more and more versions of the product where released it then would take the missing 80% pile and subdivide that into 80/20 and again, take that 20% and chip away at those personas that wanted more than video.ProTip: Consider putting these personas into a deck of "Cards" and hand them out to all members in your team. As when you are discussing problems in your day to day development get into the habbit of keeping them in view when you say the words "Customer" or "Users".
You are in the patterns business.Do not fool yourself into thinking the software you are working on is unique and never been done. There are elements to the software you are making that is fresh in terms of features here and there but ultimately you are highly likely re-using existing UI patterns found in software today. The question is what UI patterns are you using and why have you changed them? That is to say which Color Modal are you going to use and why don’t you like existing patterns out there should it be different? It’s at this micro level you isolate your users actual behavior and can be majority of the time field tested with customer(s) to establish what is “usable” and which isn’t. It is also at this point you can attach “who” the UI pattern is designed for. If you catalog these UI patterns you can also begin the “visual” treatment process before any code is even written (in parallel) as its really about which assets are missing, which you already own and when they can be queued for delivery. Lastly and the most important point of all is that you can identify which Patterns are “Fresh” and begin your patent application(s) for retaining your intellectual property rights whilst at the same time ensuring that you’re not infringing on other existing patents out there. (i.e. have you read the terms & conditions of Office Ribbon, Adobe vs. Microsoft legal case around panel snapping etc.?)
Discovery integrates with delivery.To recap, you have taken the simple “user stories” and you have mapped them into visual stories that help illustrate the “before” and “after” in terms of refining them down into “simplicity”. You have also identified whom the actors or “user” actually are finite detail that even talks to what, where and how.
So, discovery phase is done right?No. This is the easy part as now you have information and you have a sense of possibilities. What comes next is the part where you often will lose the executive owners of your team. It’s the prototyping phase of discovery, that is take your ideas and come up with some wireframes or small time boxed interactive prototypes of how the comic stories can be achieved. I say you lose them as if you do not handle this carefully you will position this phase as being “wasteful” or “not as important – function vs. form”. The trick is to factor this phase as being part of your “delivery” but knowing it is actually more to do with “discovery”, (it is as if you Jedi mind tricked the project management & executive fears). Prototypes, Wireframes and Comic Stories are deliverable that works the same as actually writing the code itself in a normal agile scenario (i.e. they too can follow sprint cycles). You can do it parallel (if you are in v2 of this process) or you can do it sequential but the key is to deliver something that shows the investment is not wasted. You also iron out the unknown and can often deliver drops to candidates for the software(s) release to get a sense of what success/fail will look like had you spent months coding it for real. Remember Windows Longhorn? Yeah most of that was Macromedia Director. Remember Silverlight on the Nokia N9 back in MIX keynotes? Yeah that was kind of a mini PowerPoint style animation! Point is when you demo something, nobody 99% of the time asks to see how many lines of code it took to make. This approach builds confidence that your development has balanced the feature(s) required with market readiness/attractiveness whilst at the same time maintains a disciplined delivery schedule. It also allows you to really validate your UX personas against the features that they are attached to, as then you can start to formulate a fairly accurate understanding of what feature(s) are going to make the release and who they are being targeted for. Having just this alone can improve your “feature” cutting when the time for reducing scope occurs; again, you know more about the impact than a general “user” statement. It also helps to know this when forecasting costs for a new products development, which is how much this will cost to produce and who the first, second, third round of releases will likely excite. It also helps training / documentation teams begin preparing their work streams on how to manage change management issues. This also helps testing teams understand how to attack their tests to ensure the said quality gates are kept intact and aren’t being approached from “generic” scenarios (i.e. play the role of the UX persona not the roles like “let’s see how much of this I can break”). Finally, it helps Marketing/Sales teams get actually ready for the “launch” in a way that hits your target market squarely in the places it should. I.e. they know who to avoid making eye contact with during launch time should that UX Persona group not make the cut).