Я создаю блог на jekyll, стилизованный под bulma.io. Я хочу, чтобы в макете _post всегда было <p>text</p> всегда соответствовать is-half has-offset-one-quarter столбцу и images было is-fullwidth
Так что, когда я создаюновый файл уценки, и он отображает на моем сайте, что текст хорошо содержится в контейнере половинной ширины, и все изображения имеют полную ширину, как на medium.com
Jekyll генерирует HTML автоматически из файла .md и для каждогострока текста обернет их в соответствии с <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>