我正在建立一个以bulma.io风格的jekyll博客，我希望_post布局的<p>text</p>始终与is-half has-offset-one-quarter列匹配，而images为is-fullwidth
因此，当我创建一个新的markdown文件并将其呈现在我的网站上时，文本很好地包含在一个半角大小的容器中，并且所有图像都是全角的，就像在medium.com上一样
Jekyll从.md文件自动生成html，并且对于每个文本字符串，都应使用相应的<tag>
我希望所有
都和is-two-third一样宽
宽达is-fullwidth
我应该创建什么班级来做
这是页面的一部分
<body>
<div class="section is-normal">
<div class="content is-medium">
<div class="container">
<div class="columns">
<div class="column"></div>
<div class="column is-two-thirds">
<p>Mid 2017, my product manager and I were reviewing our strategy for the future of the apps. As we went through user feedback it became apparent that our biggest customer issue was the impossibility to purchase more than 1 item at a time. Wait… what?</p>
<p>Our service is a complexly built system with — in most parts — the customer in mind, coupled with an extremely lean culture, minimising product increments to the bear minimum, using behavioural data proxied from 15 years of online card sales. As our OKR at the time was to move the app average order value (AOV) needle, we knew that resolving the number one customer complaint had to become the priority.</p>
<h2 id="the-context">The context</h2>
<p>The app was brought back in-house several years ago and was built by an agency focusing on our USP: personalised cards. As the company strategy evolved, as well as the product offering, the customer journey had had to be adapted but never rebuilt to scale. Flowers and gift had been added, becoming not only a card retailer, but a destination for celebrating special moments. This was all great, but from a digital product perspective our app was falling appart. Our customers expectations had completely out scaled our product and it was starting to make a lot of noise.</p>
<p>The journey on the app at the time was as follow:</p>
<p>Customer journey back then.</p>
<p>As a non user, you might say that doesn’t seem too bad? (And you are right) . Most of our customers were happy with this journey. A single linear card purchase flow, for a single occasion in mind. No less, no more.</p>
<p>As this experience had been designed to serve a specific persona, a lot of scenarios had been avoided and did not allow users to achieve their adjacent tasks. <em>What if I need to go out of the app whilst designing my card ? What if i’m taking a lot of time to purchase my card? What if I get interrupted by a phone call? What if I loose my connection when i’m on the tube ? What if I want to try several options ? What if I need three cards ? So many missions an e-commerce app should look into.</em></p>
<p><strong>We identified two major problems.</strong></p>
<ul>
<li>If you leave the app before checking out, you will loose everything you’ve done.</li>
<li>If you want to buy more than one item, you have to place each order separately. Which means more shipping cost, more orders, more troubles.</li>
</ul>
<p>From a customer point of view this is not acceptable and that’s why we were resolved to fix it. From a business point of view, it was a different story… This specific journey — although identified as a major customer pain point— had the highest conversion rate we had ever seen for an online retailer.</p>
<p><strong>Over 30% to be relatively precise</strong></p>
<p>The rules of the game had changed from a simple user problem to a complex business problem.</p>
<h2 id="in-a-stakeholders-meeting"><strong>In a stakeholders meeting:</strong></h2>
<blockquote>
<p><strong>Us:</strong> <em>“how much of our conversion rate can we trade off for a higher average order value?”</em></p>
<p>**Stakeholders: **<em>“none”</em></p>
<p><strong>Us:</strong>
not sure what to say…</p>
</blockquote>
<p>This business position had a massive impact on the release strategy of our project, but we were going to try our best to succeed</p>
<p><strong>Our goal was now:</strong></p>
<blockquote>
<p>Allow customer to buy as many items as they want in a single transaction, whilst not impacting conversion rate…</p>
</blockquote>
<h2 id="empathise--with-our-customers-and-the-business-too-">Empathise ( with our customers and the business too ?)</h2>
<p>First thing first, there was an initial immersing phase around the platform. I spent days searching, reading, questioning and mapping how the whole tech was working. Defining the business logic behind. Then started investigating competitors and listing functionalities our customers should expect from a typical e-commerce shopping cart on day first release.</p>
<p>Best way to understand a piece of tech: Draw a diagram of its logic! yay…</p>
<p>I then conducted several workshops with our engineers, product and UX in order to understand what was the current situation, (mostly for the client side). Was there any reusable element/component in the app? What would be the fastest way to develop such features? What would be the least disruptive for our customers? How could we keep learning as we build the new basket? How could we minimise the risk?</p>
<p>Both iOS and Android scratching their heads…</p>
<p><strong>Soon after the answers were radical:</strong></p>
<ul>
<li>Nothing could be reused.</li>
<li>New endpoints had to be created and mapped onto the current backend logic.</li>
<li>App architecture needed rethinking.</li>
<li>Refactoring would be too long.</li>
<li>Risk was high.</li>
</ul>
<p>As we knew we could not offer less functionalities to users than the current live app, (considering the business constraints) and there was no way we could go offline for 6 months. We had to find a way to iteratively deliver those initiatives without disrupting the current app.</p>
<p>Creating a shopping cart in e-commerce, unfortunately might not be the most creative project you will have the chance to work on, throughout your career. Using our current behavioural data and loads of reading from various website like the <a href="https://www.nngroup.com/search/?q=cart&searchSubmit=Search">Nielsen Norman Group</a> I created a map of the future user flow. Which we used as a visual token (using Google Drawings) for what we wanted to deliver. This document would be iterated on, and used to map API calls and help engineers discuss implementations details and blockers. A living document to support our explorations.</p>
<p>With a defined end goal, our senior engineers came back to us with their dev strategy.</p>
<p>Iterative implementation at its best</p>
<p>We would build and insert a new screen before “checkout” that would hit the new API and become the future basket, allowing them to work their way backwards in the journey releasing one screen at a time and split testing each increment.</p>
<p>one release had to have two new screens which we A/B tested against the current journey</p>
<p>Having our user flow clarified and a release plan, I started focusing on the prototyping (using tools such as proto.io and Flinto) working throught out the journey (happy path first), one chunk at a time and started gathering qualitative feedback from our users; each new prototype competing with the current live solution. The idea here was to uncover unknown unknowns and reduce the risks as we simplified our UI and introduced new interaction patterns.</p>
<ul>
<li>User adds a card then a gift</li>
<li>Selecting a recipient</li>
<li>Clarify the concept of direct recipient</li>
<li>Selecting a shipping date</li>
<li>Selecting a postal option</li>
<li>Change a product option (i.e size)</li>
<li>User adds two cards</li>
<li>Users wants to send a card to his mum and flowers to his wife ?</li>
</ul>
<p>screen recordings of prototypes : Add a card then a gift — Creating a recipient — Pick a delivery date</p>
<p>Have a break, have a rebrand. As a little break in our project we had to deliver MVP1 (lipstick on a pig…)</p>
<p>As the rebrand was happening, I kept building prototypes and testing micro-interactions, for handling edge cases, our micro-services had to offer. (handling errors for example…)</p>
<ul>
<li>User errors</li>
<li>Network errors</li>
<li>Validation errors</li>
<li>Business logic errors I’m ?</li>
</ul>
<p>Every blue square is an error UX needed to handle</p>
<p>The truth about legacy systems is that you don’t want to work with them. Especially as a product designer, your whole mission is to solve problems, find shortcuts and optimise, in order to move faster. A legacy application will potentially do everything against those ideas. It is not built to scale. It was built for a reason of the past. As a result, making it do something it was not built for is a real challenge.</p>
<p>examples of handling errors on the new shipping and basket.</p>
<p>We finally manage to release our new shopping cart. With the lack of time and other constraints, a lot of my work had been stripped out and postponed for further iterations. Lovable from a customer point a view, and viable to learn from, from a product point of view. The journey is connected on both end and we have not changed too much the previous global journey. We released, under feature flag, a 50/50 test between old journey and new journey for 1 month to collect enough data to validate that our initiatives were driving the correct behaviour.</p>
<p>Our users could now add as many product as they want to an order. Moreover at the moment they have their personalised card added to their cart, it is saved remotely until purchased or deleted.</p>
<p>As part of the results of the initiatives we noticed</p>
<ul>
<li>Users had a higher average order value +11%</li>
<li>User used “continue shopping” after adding an item to their order.</li>
<li>We fixed 60% percent of bad user reviews on the AppStore.</li>
</ul>
<p>Current user flow on the iOS app</p>
<p>Now that our funnel was live, we kept looking at our GA event for user behaviours, We then started drafting hypotheses on how we would actually diverge from the current basket behaviour in order to move towards a more traditional e-commerce basket.</p>
<ul>
<li>Only 7% of our users actually change the shipping option. By skipping the shipping screen and making it optional, we will improve our conversion rate by XX%.</li>
<li>Reducing friction when adding an item, should increase the number of items added to basket and reduce the number of lost customisation.</li>
<li>By Postponing the recipient selection to the moment of checkout we might increase our average order value.</li>
<li>Allowing user to preview their order before checking out will increase conversion rate.</li>
</ul>
<p>Future iteration of the basket</p>
<p>An iterative process that kept me busy for a long time. (9 months). Including inspiring meeting, intense discussions against de scoping, and never ending compromises between dev, product and design. This was the real stuff.</p>
<h2 id="lessons-learned">Lessons learned</h2>
<ul>
<li>The more deeply engaged a user is, the more likely to convert.</li>
<li>Shopping carts should not be built in house. They should be outsourced</li>
<li>Providing less than other e-commerce competitors will cause issues. Amazon is the new standard</li>
<li>Checkouts can always be optimised But is it worth it ?</li>
<li>Make sure when you start working on a checkout that you have all pieces of the puzzle before even planning.</li>
<li>You need a great team synergy to deliver such initiative.</li>
</ul>
<p>Thank you for reading all the way through the end. If you have feedback or comments about that project please leave a comment or get in touch @edbattistini</p>
</div>
<div class="column"></div>
</div>
</div>
</div>
</div>
</body>