We believe in a cyclical, evolutionary approach to product development.
We thought that maybe you guys would find it interesting how we come to design decisions surrounding new ideas or developing and refining existing feature sets. I’ll also talk a bit about Scatter Simple, part of our upcoming update to Scatter wallets.
We have gone through a lot of iterations in the last two years, and it will be interesting to stop and take a breath and try to understand why some of the decisions were made, and where we would like to go.
A “deep” tree of nested screens is definitely not the way to go. Some features of Scatter version 10 were three or four screens deep and users simply weren’t finding them.
Because of this we developed a more “flat” user interface which exposed more of the settings directly to the end-user. Unfortunately we defaulted to a collapsed sidebar by default and users had a hard time finding things like “Networks”. Version 11.0.1 was in the wild a long time and many users complained (legitimately!) about things like – how to manage app permissions – how to exchange tokens. – users not understanding how to update keys for their accounts.
In version 12 we strove to continue our streamlining approach. – It is now fully responsive (because mobile!) – The menu is open by default, and it is more obvious how to collapse it. – In wallets, accounts are more clearly grouped under their keys – The app explorer is cleaner and it is now clear which are promoted apps and which are not – and of course most of the real work went into making Scatter Embed, our secure update mechanism. You can read more about that in another article we’ll be releasing soon.
We think that on the whole it has gotten easier than ever to use Scatter, and easier for us to maintain. That being said, there is still a ton of technical functionality that caters to “advanced” users with dozens of keys and potentially hundreds of accounts across multiple blockchains.
The key takeaway here is that at some point we have to ask ourselves who our target audience is. Is it for advanced, technical users or is it for more mainstream users who just want to play a game, gamble securely, or edit a page on Everipedia? We think you know what the answer to that is.
Part of what I like about working at Scatter is the open nature of the design discussion. Since it is an open-source project and developed for a very specific community I have the opportunity to directly engage with the community and get feedback on what works for them and what (sometimes really) doesn’t.
For the most part our users are on EOSIO blockchains, with some small amount of Bitcoin, Ethereum, and Tron users sprinkled in there. EOSIO itself is really cool technology that is just now getting its feet under it. There are some stability and governance issues that need working out, but it is very cool to watch decentralized networks with hundreds of smart contracts on them doing almost 45 million operations a day. There are hundreds of thousands of people around the world using this stuff and it feels like touching the future when you log on to the new, advanced networks with your shiny, new account. Like the internet in the early 90s, it is small, colloquial, and generally unknown to the wider world. It is also not well connected, as in each of the networks is largely silo-ed off on its own. Inter-blockchain network communication is still a ways off, but making good progress.
However, EOSIO is kind of an odd-duck blockchain technology when it comes to user-experience, and that makes for a headache when designing software for accessing it.
It has an accounts system that is permissioned, and feels more akin to an account system on Unix than something like Ethereum where you just have a keypair that uses a formatted public key as the address. EOS accounts are easier to interface with as a user as you don’t have to type in long strings of alphanumerics to do transfers, but managing them is more complicated and prone to user-error.
You generally have an account permissioned like this:
But in principle you could have something like this, too:
Where each set of key pairs has functionality that it has access to through your account. It’s wonderfully flexible, but I’m never going to be able to expose this kind of tech to “regular” people because they just don’t care and don’t need it.
This is us creating UX for doing uncommon tasks, and I think that for mainstream acceptance, we need to change how we look at blockchain technologies like EOSIO.
It is time to make a cognitive switch and build for mass appeal.
Scatter Simple basically provides the user an EOS account without any of the complexity exposed. No account permissions, no confusing keys, no resource management, etc. Just the basics. Just go play your game.
To get there we had to walk a certain path that taught us what works and what doesn’t.
What we are encountering as we go through the process of building out these technologies is that we still don’t know what the right way to do things really is because, frankly, nobody has every tried to do it before.
Experience is defining the design of the future.
We’d like to keep Scatter Simple as easy to use as we can, while not painting ourselves and the end-user into a corner when it comes to functionality.
One of the places this has hit us is in the case of an “advanced user” who wants to use Simple mode in Scatter 12. Scatter Simple’s UX and UI is based around the concept of “just one account” to remove a lot of the UX complexity. But what happens if the user actually has multiple keys and accounts that they want to switch through easily?
We have to support advanced functionality, but make it as easy to use as possible.
Currently in Scatter 12 you see this in your “Wallet”:
It’s complex, but it tries to be organized and allow the user to understand the concept of accounts being tied to keys without being too complex.
Scatter Simple has a simpler approach
People still find this really hard to understand so in Scatter Simple we are going a step further and making this interface more intuitive.
The ability to change your “default” account is located in the settings panel, where most normal users (who automatically only get 1 key account when first creating their wallet) will never need to go, but where advanced users are used to browsing.
Each key is encapsulated, and cleanly shows accounts attached to it as actionable items.
Adding new accounts is clear and easy
Export, refresh, and delete are clearly exposed per key, so those actions are easy to find.
Importing from hardware is more clearly defined so that users can see which index and public key they are importing, again as actionable items.
We hope that this article has given you some insight into how we at Scatter make design decisions based on real user feedback. It is critical to us that the interfaces which we build have a positive impact. For all of you out there that feel that what we are building is too hard to use, too confusing, or too much: we hear you and are trying hard to build a better Scatter.
I just need to put two boxes side-by-side and I hear flexbox is good at stuff like that.
Just adding display: flex; to the parent element lays out the children in a row.
Well, that’s cool. I guess I could have floated them, but this is easier.
They should probably take up the full space they have though. Can I just stretch the parent to 100% wide? Well, I can, but that’s apparently not going to affect the child elements.
If the parent element has more space than the children need, it doesn’t do anything to help the children fill the space alone.
Maybe I can use width: 50%; on the children? That works, but I thought the point of flexbox is that you don’t have to be all specific about width. Ah yes, flexbox has all of these ways of expressing the growy-shrinky-initial behavior of children. Looks like flex: 1; is about as easy as it gets here.
Applying flex: 1; to the children allow them to grow and fill the space.
I like how I haven’t had to do any math or hard code values so far. Can I make it a three-up pattern without touching CSS?
Nice.
Hmmm, wait. The sizing is a bit, uhhhh, flexy? Nothing is forcing these boxes to be one-third of the container all the time.
Looks like flex-basis: 33% doesn’t fix this. flex: 0 0 33%; also doesn’t do the trick. Looks like width: 33%; flex-shrink: 0; does though, if we’re really wanting to strongarm it.
Sometimes a design calls for exactly equal size boxes. This is maybe CSS Grid territory, but whatever.
The long word forcing that sizing behavior at narrow widths is perhaps an uncommon scenario. We could have also solved it with word-break: break-word; hyphens: auto; on the child.
Another thing we could do it just let the dang items wrap instead of being so strict about it. Flexbox can do that, right?
Oh hey, that reminds me how cool it is that those first two items are the same height. That’s the default stretch behavior, but it can be controlled as well. And it’s by row, which is why the second row has its own different height.
What if I want that first “Love” block to be on top instead? Looks like I can re-order it, eh? Let’s see, the default order is 0, so to be first, I do order: -1;.
Ha! That kinda worked. But I meant that I want it to take up the full width on the top row. I guess I can just kick it up to flex-basis: 100%; and the others will wrap accordingly.
It’s pretty weird to have the source order and visual order different like this. Maybe that should go in the “don’t ever do this” category.
What if I wanna bail on the whole flexbox thing at a certain point? Part of me wants to change the direction to go vertical with flex-direction: column; and force the children to be full-width. Ah, a simple display: block; on the parent does that in one swoop.
Rather than changing all the flexbox stuff to handle a column layout, we just turn flexbox off.
Flexbox can do way more stuff! One of my favorites is how auto margins work to “push” other elements away when there is space. This is just one little journey playing with some UI and seeing the useful things flexible does along with things that can make it confusing.
This is the UX Design Process Best Practices ebook, written by Jerry Cao, Ben Gremillion, Kamil Zięba, and Matt Ellis, and originally published on UXPin.com.
Usability testing makes the difference between design thinking (designing for the user) and the outdated modes of thinking favoring features, businesses, or the product itself. The latter test only at the end to validate their ideas, while design thinkers test throughout the process to generate their ideas.
The cycle of iterating, testing, and implementing the feedback will chip away at all the imperfections until all that remains is the best possible version of your product.
In this chapter, we’ll outline the four steps of usability testing (and the documentation that occurs in each):
1. Define Goals — Determine which questions you want the test to answer.
2. Prepare the Test — Determine which test will answer your questions, then plan the best way to conduct it.
3. Conduct the Test — Recruit participants and administer the test.
4. Present Results — Compile data into an easy-to-understand format and share it with your team-members.
We’ll start with the planning phase.
1. Define Goals
The first step to any successful usability test is defining your goals: what questions do you want the test to answer. This could be broad, such as,
Which checkout methods are most intuitive to our users?
Or specific, such as:
Which form design works best for increasing e-commerce purchases?
The important thing is that you know why you’re conducting the test. Knowing where you’re going will let you find the best route there.
Naturally, you’ll have a lot of questions about your product, and this curiosity is good. However, remember to limit each test to only the most relevant issue at the moment. Each test should have a central focus for the most accurate results — the more objectives you test at once, the more room for error.
This is another advantage to testing often: you can address each issue with the attention it deserves. If you find yourself with too many questions, make a list and prioritize the questions based on the steps of the design process. You can always save this list for later tests.
Deciphering these questions will automatically set your mind to think up answers on its own. As David Sherman mentions in his article on usability testing, these potential answers will be your test’s hypothesis. By stating the hypothesis outright, you can draw attention to any potential bias in order to prevent it, and will also help you communicate the results later (“we originally thought this, but then discovered this”).
You can generate hypotheses simply by setting aside time for you and your team, to try to answer the goal questions on your own.
2. Prepare the Test
There are literally hundreds of types of usability tests to choose from, each one with their own special area of expertise and their own limitations. It’s not about knowing which tests work and which don’t, it’s about knowing which will work for a specific need. That’s why defining your goals first is crucial.
1. Scripted — These tests analyze the user’s interaction with the product based on set instructions, targeting more specific goals and individual elements. (tree testing, hallway usability tests, benchmark testing)
2. Decontextualized — Ideal for preliminary user testing and persona research, these tests don’t necessarily involve the product, but analyze more generalized and theoretical topics, targeting idea generation and broad opinions. (user interviews, surveys, card sorting)
3. Natural (or near-natural) — By analyzing the user in their own environment, these tests examine how users behave and pinpoint their feelings with accuracy, at the cost of control. (field and diary studies, A/B testing, first-click testing, beta testing)
4. Hybrid — These experimental tests forego traditional methods to take an unparalleled look at the user’s mentality. (participatory design, quick exposure memory testing, adjective cards)
Before you test your users, you might also send out a user survey.
Obviously, these aren’t usability tests, but they certainly contribute valuable research to the testing process. You’ll want to include a mix of the following types of questions:
• Multiple Choice — Whether the user selects from an assortment of prewritten answers, or simply just yes-or-no, multiple-choice questions allow you to easily categorize answers and give you control for specialized data, but do not allow user insight and risk being biased. These lean towards quantitative.
• Verbal (or Written) Responses — Asking users open-ended questions and encouraging their elaboration may reveal some insights you had not anticipated. However, you are at the whim of how well the user can articulate themselves, and this data can be difficult to categorize and therefore analyze. These lean towards qualitative.
• Rating Scale — By asking users to rate their feelings on a numeric scale, you’re able to capture qualitative data in a quantitative way. This allows you to analyze a user’s feelings in a concrete way.
Once you determine the type of usability test(s) to run, you should send out a descriptive announcement to give your team a heads up. It’s even more helpful, in fact, if you summarize your tactics with a quick planning document.
Modified from Tomer Sharon’s One-Pager (fantastically helpful yet lightweight), our research plan document is a formalized announcement with all the necessary details of the testing to both explain what’s happening and invite collaboration.
1. Purpose
In addition to keeping the test planners organized, the research plan lets the entire team know all the relevant details about the test, and gives them the chance to contribute their feedback or improvements before the test is conducted. It also appeases stakeholders seeking a bottom-line assessment.
2. Best Practices
Brevity is the name of the game with research plan documentation. You want to hand your team a slim document around one page to encourage them to actually read it.
While keeping things brief, you’ll want to cover at least these 7 sections:
1. Background — Here is where brevity is important. In a single paragraph, describe the reasons and events leading to the research.
2. Goals — In a sentence or two (or bullets), summarize what the study hopes to accomplish. Phrase the goals objectively and concisely. Instead of “Test how users like our new checkout process,” write “Test how the new checkout process affects conversions for first-time users.”
3. Questions — Here is where you elaborate if needed. List out around 5–7 questions you’d like the study to answer.
4. Tactics — Where, when, and how the test will be conducted. Explain why you’ve chosen this particular test.
5. Participants — Describe the type of user you are studying, including their behavioral characteristics. You could even attach personas (or link to them) for more information.
6. Timeline — The dates for when recruitment starts, when the tests will be expected to take place, and when the results will be ready.
7. Test Script — If your script is ready, include it here.
Encourage your team members to give suggestions or advice so that the test results are helpful to everyone. Find out the questions that they want answered as well.
3. Conduct the Test
After gathering feedback from the team, you’re ready to actually conduct the test. This involves recruiting the right participants, scheduling times, and writing the actual test documentation.
For recruiting users, stick to your target audience defined at the onset of the design process. These are the same types of people who influenced your personas. If you’d like help reaching out to these people, Jeff Sauro, founder of Measuring Usability LLC, lists 7 methods for user recruitment, including online tools. In our experience, we’ve found hallway testing and tools like UserTesting incredibly helpful (part of the inspiration for integrating usability testing into UXPin).
As for your role during the actual test, sometimes you must make the choice between being present (moderated) or allowing the user to work on their own (unmoderated):
• Unmoderated — Unmoderated tests are cheaper, faster, and generally easier to recruit and schedule. They also remove the influence of a moderator, leading to more natural and less biased results. On the downside, there is less opportunity for follow-up questions or supporting users who go astray during tests. Moreover, you put yourself at risk of finding users only interested in the compensation, thus reducing the quality of the results.
• Moderated — While costlier and requiring more effort to organize, moderated tests allow you to “lead” the user, for better or worse. Moderated tests are recommended for rougher prototypes (higher risk of bugs and usability issues) or incredibly complex prototypes (users might need some clarification).
Additionally, you can also choose to conduct your test on-location or remotely. While every test has different qualities and best practices, the following advice works across the board:
• Make user is comfortable — Even the word “test” makes people a little nervous, so put in extra effort to put them at ease. Remind them you are testing the product, not their capabilities. A test script helps ensure you hit upon a few reassuring points in the beginning of each test.
• Test competitor products — If applicable, use competitor products as a frame of reference. This distinguishes whether your user’s opinion exists independent of your product, or as a consequence of it.
• Don’t interfere — Unless the user is at a complete standstill, sit back and allow them to figure out the product on their own and make mistakes. This avoids bias and may reveal insights into user behavior you hadn’t predicted. The best insights usually come from when a user isn’t engaging with the product the way it’s designed. Pay attention to workarounds and let them inspire feature improvement.
• Record the session — This makes a solid reference point for later, when interpreting the results.
• Collaborate — If you have a team observing a moderated user test, Tomer Sharon (mentioned above) suggests creating a Rainbow Spreadsheet, a shared observational sheet that allows everyone to record their own interpretations of the data for quick and easy comparisons later. We used his spreadsheet during our Yelp redesign exercise and found it was very helpful for summarizing results for designers and stakeholders.
Testing for mobile products, especially, require care and attention, given the technical difficulties. For advice specific to this, read Rosie Sherry’s article, A Field Guide To Mobile App Testing.
Of course, the way you write the actual tasks will also influence the results.
As the name suggests, user tasks are what the user tries to accomplish during the test.
1. Purpose
Well-defined user tasks make the difference between an organized procedure and simply “winging it.” More-so than simply telling the user what to do or posing them questions, it accounts for the purpose of the test.
2. Best Practices
Everything you present to your users during the test — both the content of the question/task, as well as the phrasing — impacts how they respond.
Tasks are either open or closed, and your tests should incorporate a healthy mixture of both:
• Closed — A closed task offers little room for interpretation — the user is given a question with clearly defined success or failure (“Find a venue that can seat up to 12 people.”). These produce quantitative and accurate results.
• Open — By contrast, an open question can be completed in several ways. These are “sandbox” style tasks (“Your friends are talking about Optimal Workshop, but you’ve never used it before. Find out how it works.”) These produce qualitative and sometimes unexpected results.
As for the wording, be careful to avoid bias. Just one wrong word can skew results.
For example, if you want to find the most natural ways in which users browse your online shop, writing a task like “It’s 10 days before Christmas and you need to search for a gift for your mother,” might lead the user to use the search functional, as opposed to their normal method of window clicking.
3. Present Results
The point of the testing, is, of course, to collect data to influence design. But if you don’t present the results effectively, or at all, the entire testing process is a waste.
The usability data from tests can, and often means the difference between success and failure. For example, Venmo, a money-exchanging app, took the data from its analytics and used it to fix a critical error.
But it was not as simple as that. First, the support team brought the problem to the product team, who collaborated with the data team. The data was analyzed in a helpful way through Looker, which showed them the problem in a way everyone could understand.
After that, it was a quick fix.
From the Venmo example, which you can read about here, we can identify the two criteria for success at this stage of the process:
• presenting the results in a way that’s helpful
• sharing the results with the team in a uniform way
This phase is about taking raw data — sometimes even just numbers — and turning it into something useful. It’s not just enough to conduct tests, you have to show the results the right way, and then share them.
The usability report is the way to share the results with the team, so that everyone’s on the same page.
1. Purpose
First, the usability report is a universal document (or, more accurately, a collection of documents) that everyone on the team can reference. It makes sharing easy, especially with a cloud folder (see below) where everyone can access the same information.
Collaboration, in general, is a key aspect of this stage, if for no other reason than to remove bias. The more people to comment on the notes, the less influenced they are by personal interpretations. As Alla Kholmatova describes, a second evaluator increases problem detection by 30%–43%.
Furthermore, documentation of the test helps down the road. Later in the design process, you may want to draw on the notes of the testing, in which case you’ll be glad for an easily accessible formal report.
2. Best Practices
To best organize and make the results readily available, we suggest creating a cloud folder with universal access. At UXPin, any team member can read or reference the latest results at any time.
As you write the report, keep the following tips in mind:
• Avoid vagueness — Mentioning that “Users couldn’t buy the right product” isn’t very helpful since multiple factors might be involved. Perhaps the checkout process was difficult, or the product listings were hard to browse. Explain the root of each issue from an interaction design and visual design perspective (e.g. confusing layouts, a checkout process with too many steps, etc.).
• Prioritize issues — Regardless of how many issues you find, people must know what’s most important. We recommend categorizing the report (e.g. Navigation Issues, Layout Issues, etc.) and then adding color tags depending on severity (Low/Medium/High). List every single issue, but don’t blow any out of proportion. For example, don’t say that a red CTA button lead to poor conversion if the steps of the checkout process don’t make sense.
• Include recommendations — You’re the expert and stakeholders need an action plan. Don’t include any hi-fi prototypes or mockups in the usability report, but definitely suggest a few improvements. To supplement written suggestions, our own UX Researcher Ben Kim also links to lo-fi wireframes or prototypes in a UXPin project dedicated to usability testing.
When presenting the results, include any and all relevant materials. The usability report should be a folder, not a single file. Don’t forget to include things like:
• Formal usability report,
• Supporting charts, graphs, and figures,
• Previous testing documentation (i.e., the list of questions the user was asked),
• Videos or audio tracks of the test (which is why it’s good to record sessions).
Finally, do not treat the usability results as a folder meant to be handed off. The documentation is just the starting point. Schedule a follow-up meeting with the team to review the usability report and relevant data, discussing issues and the outlined recommendations.
User testing insights speak far louder than guesswork and conjecture. They help guide design decisions and serve as powerful evidence to counter people’s opinions.
Don’t wait until the end of the project to conduct your usability testing.
Once you have a lo-fi prototype, start testing. The data is less about validation and more about inspiration: test early, and test often, so you can actually put the results to use before it’s too late.
The big misconception I’ve seen designers and developers often fall victim to is believing that handoff goes one way. Designers hand off comps to developers and think their work is done. That puts a lot of pressure on the designer to get everything perfect in one pass.
It seems overly simplistic, but the best way for designers and developers to start trying The Hot Potato Process is to sit together. We’ve seen many a designer developer pair who have worked together for years become enlightened as to how the other works within the first few minutes of sitting together.
The first piece of pushback we often get about The Hot Potato Process is that it seems ideal only for co-located teams. But, as increasingly more people are working remotely, good processes should adapt to all the different ways that people work; the Hot Potato Process is no exception to that.
If you can’t sit together in person, use video chat and other real-time synchronous tools to simulate working together in a co-located way. My teams will often leave a Zoom chat open for a few hours as a proxy for being in the same office together, even if we’re not talking to each other the whole time.
If you can’t work at the same time due to time zones not lining up, you can record yourself working and send it to your collaborator. Your collaborator can then work alongside your recording while making their own recording. Then continue to pass recordings back and forth. Tools like Voxer, Marco Polo, and other walkie-talkie- and intercom-like apps help to make asynchronous collaboration feel a bit closer to synchronous collaboration.
If you can’t sit together in person or trade recordings or approximate these kinds of approaches, you might have to come to terms with the fact that you’re not truly working together.
Veerle is one of the fascinating minds behind Duoh!, whose love for design in all its various forms shines through. She is a graphic/Web designer hailing from a … More about Veerle
Pieters …
Back in 2016, Vitaly Friedman asked me to design the cover and layout for a printed version of Smashing Magazine, a magazine for web designers and developers. The design I created back then for the cover and inside template layout, however, was shelved for a while as the project was paused for about two years owing to other priorities. Later, after Smashing Magazine launched its new website, a new style was born, and the design I had come up with didn’t really match anymore. So it was dropped.
Around mid 2018, the project was reignited, and I was asked to design a new layout template for the magazine. Later, around the beginning of this year, I also redesigned the cover. Now, the pilot issue of a shiny new Smashing Magazine Print has been launched.
I’m very happy they chose my initial design of the table of contents, as I was really fond of it myself. The version I created later (see the above image to the right) was very different, since I went for something closer to the current design style.
In my first design back in 2016, I could choose the typefaces, and I had total freedom over the design style. It was totally different — very geometric and more modernistic. So I was very happy to see that some of the designs were adopted in the magazine’s final layout, like the table of contents and this page design for the introduction.
Reshape to Fit the New Design Style
The challenge now was to reshape the design to fit the current style of orange-red roundness, and cartoon cats. The answer was, of course, very simple: start from scratch.
Brainstorming and Sketching
Fortunately, the theme of the first edition had been identified, which made it easier for me to think about a suitable illustration. Smashing Print #1 would be about ethics and privacy. My first idea in terms of the overall design concept was to try out something along the direction of Noma Bar’s negative space design style. That’s easier said than done, of course, but I thought it would be awesome if I could pull it off and come up with something clever like that.
After writing down a few keywords (spying, watching, tracing), things like an eye, a keyhole and a magnifying glass came to mind as suitable subjects to use in my illustration. As for “tracing” I thought of a trail of digital data, which I saw in the shape of a perfect curvy line with ones and zeros. So I doodled a couple of basic ideas.
Inspiration Browsing
While designing this cover I did a lot of browsing around. Here are a couple of images that inspired me. The bottom-left one inspired me purely in terms of the layout. In the top-right one I really like the rounded shapes, plus its simplicity and contrasting colors. The middle-top and bottom-right ones use cute figures and a fun, vertical 2D approach. The top-left one has nice smooth shapes and colors, and I like its strong image. There were more images, for sure, but these five did it for me.
Images that inspired me for the cover design. (Large preview)
First Design
Choosing Colors
I often start a design by choosing my color palette first. The colors I picked here were chosen purely because I felt they go well together. I wasn’t sure I would use all of them, but somehow I’m used to having a color palette in circles placed above my artboard. Then I use the color picker tool to select the color fill I want to apply, or I select them all and make them global swatches.
Then I worked with the doodle of the magnifying glass as an eye in Illustrator and played around with a bit of color and composition. I thought adding some colored bars at the bottom would give the illustration an eye-catching touch. They represent digital data gathered from users, converted into analytical graphs.
I ended up with the design shown to the left. (Ignore the name of the magazine, as this was changed later on.) I wasn’t sure how much of the Smashing orange-red I should use, so I tried out a version with a lot of orange as well, even though I preferred the other one.
While I did like the result, the idea of doing something with a trail also appealed to me as a second concept. I visualized a person walking around with a smartphone leaving a literal trail of all their interactions. That trail was then picked up, and zoomed in to and saved and analyzed. At the beginning of the trail I added a magnifying glass. I would have also mixed in some graph bars, but at this point I didn’t know where or how exactly I would incorporate them into my composition, though I was already playing with the idea of using some sort of rounded shape background, combined with some subtle patterns.
Typically, I don’t sketch out my entire design. I only quickly doodle the idea and sketch out the elements I need in more detail, like the person with the phone. Once I had the concept fixed in my mind, I started out designing in Adobe Illustrator. First, I created a grid of guides to be used for the background shapes, and also for positioning the trail and figure. There were a couple of steps to get to this final design.
Final Design
Setting Up a Grid
The inspiration image at the bottom left encouraged me to go for a layout with a lot of white space at the top for the title and some white space at the bottom to add three key articles. As for the illustration itself, I envisioned using a square grid, perhaps going all the way over the spine and back.
Final cover design shown in Adobe Illustrator with grid guides and layers panel. (Large preview)
I created this square grid and placed the guides in a separate layer. Once this was set up, I started with the walking man and his smartphone, positioning him somewhere at the top-left.
Next came the curvy path. I just drew an angled line on top of the grid and used the corner widget to convert these into perfect rounded corners. I was thinking of using ones and zeros on the trail, because that’s how I visualize digital data. I turned the curvy path into a fine dotted line with a very wide gap to use as a guide to place the numbers. Once I started to place the numbers on each dot, it looked way too busy, so I decided to place one tiny dot between each number.
The next thing in the process was the creation of the background. I only had a vague idea in my head: a composition of geometrical vertical shapes with rounded corners in different colors from the palette. During this phase, I did a lot of experimenting. I moved and recolored shapes over and over. Once I had the flat colored shapes finished, I started adding in patterns on top. I tried out tiny dot grids that I randomly shaped in length and width, and applied color to. This was all a matter of intuition, to be honest, trying out something, then trying out something else, comparing both and choosing what worked best: changing color, changing the transparency mode, opacity value, and so on.
The bar graphs and icons were created in the last phase, together with the magnifying glass, and the spine and back. I just kept the idea at the back of my head, and waited till I had the man and the background shapes ready. Finally, I added in some basic icons to refer to the type of action made on the data, such as geolocation.
Back Cover
As for the back cover, I had already envisioned the background composition going all the way around, only much lighter. That’s how I came up with the idea of using a light area in the center with a couple of intersecting colored lines there.
In the final printed version, text is added in the center space, nicely framed in a rounded box with a yellow border, so the composition of the lines you see here has been removed and doesn’t match the printed version.
Spine
For the spine, I’d had the fun idea earlier of having the Smashing logo build up with each release (see image at the top of the article), but the tricky thing here is that each edition needs to have the exact same thickness or the whole concept falls apart. It wasn’t realistic since I wasn’t sure each edition would have exactly the same page count. I had to remember that the width of the spine could vary. So I came up with the idea of using some sort of pattern combinations that can vary in width, but still have the magazines connected.
The general idea was also to use a different theme pattern for each issue. The pilot issue uses fine dots in combination with a capsules pattern. In the spine I use a couple of others. The idea is to achieve a coherent composition when you place or stack them in the right order, which serves also a motivation to buy all issues. ?
Drawing Can Be Really Simple
Here I’ll describe a quick process of a simple detail of the cover illustration: the creation of the walking man’s face. I know a lot of people are convinced that drawing in Adobe Illustrator isn’t easy and that you have to use the pen tool a lot, but that’s not true. You can create beautiful illustrations using only simple shapes like rectangles and circles, combined with the corner widget, pathfinder options and align tools.
Quick Design Process Of The Walking Man
If you keep the shapes in your illustration as simple, flat 2D, drawing in Adobe Illustrator can be easy. Take the head of the walking man. I didn’t even use the pen tool. I’ve only used simple shapes: rectangles and a circle, and these steps:
With the sketch in the background, I drew a rectangle for each part of the head, and a circle for his ear.
2. Align and unite
Next, I used the align options to align the shapes correctly, and the Pathfinder > Unite option, and I also moved the top-left corner point a little to the right for his nose, using the → key.
Then, with the Direct Selection tool (white arrow) I created the rounded corners for the hair and chin.
4. Arrange and apply color
All that remains is removing the strokes and applying a proper fill color for each shape. Last but not least, I made sure the shapes were in the correct stacking order by using the Object > Arrange options.
Chapter Illustrations
The chapter illustrations also have a bit of my handiwork. Below are the illustrations created by someone else, but the request came to improve them a little bit and make them full-page.
Chapter illustrations already created but needing to be improved. (Large preview)
And so I did. Below are the ones I delivered to Smashing Magazine and which were implemented in the final version.
Note: As you can see, I’ve incorporated the dotted pattern and modified some of the icons a little bit, but I kept the overall illustration style.
For the first chapter, there was no image, so that one was based on the style already in place.
The six chapter illustrations created from ones already in place (with the exception of chapter 1). (Large preview)
I hope you’ve enjoyed my design process story and the quick process tutorial. Don’t forget to check out the pilot issue of Smashing Magazine Print (view sample PDF). It’s a must-have for any web designer! Enjoy!
