small_Fcsqb5pWQAAzPIK.jpeg

thumbnail_Fcsqb5pWQAAzPIK.jpeg

Adobe acquires Figma, cue the memes 🤪

large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

Still can’t get a UX job? Give up.

large_featuredImage

medium_featuredImage

small_featuredImage

thumbnail_featuredImage

Sticking to UI/UX trends is a losing strategy

<p><a href="http://ift.tt/2nzQDu8">CSS-Tricks</a> | Geoff Graham </p>
<p>I have been asked to lead product development on a team. This is somewhat of a new journey for me because I&#8217;m generally used to <a href="http://ift.tt/1M69ROj">calling myself a web designer</a> rather than a product manager or strategist.</p>
<p>The toughest part of this job for me has been organizing my thoughts. I&#8217;ve written an executive summary for the product we&#8217;re building, done some competitive research and even dusted off my limited MBA education for a <a href="http://ift.tt/1GoGW4j">SWOT analysis</a>. Oh yeah, now it looks like I know what I&#8217;m doing!</p>
<p>Many of us who read CSS-Tricks with any sort of regularity likely have to think strategically to do our jobs, whether it&#8217;s in design, development, or both. What I&#8217;ve found, however, is that <em>thinking</em> strategically is a whole lot different than <em>acting</em> strategically. <span></span> Where thinking strategically is an internal process that stays in your head, acting strategically requires careful orchestration and the ability to document internal thoughts in a way that can be shared and understood across a team.</p>
<p>The difference between thinking and acting strategically was never truer to me than when I sat down to write feature requirements for this project. I thought I would share what I&#8217;ve learned in my early attempts to write requirements.</p>
<p>Before I get started, I do want to say that there is no shortage of ways to approach feature requirements. What I&#8217;m about to share largely borrows bits and pieces that I&#8217;ve found crawling the web for answers to my own questions and piecing them together in a way that works for me.</p>
<h3>Recognize Your Bias</h3>
<p>The first thing I had to learn to accept is that I am biased in how I approach requirements. I am a web designer by trade and, as such, my thinking tends to be on the visual side of things. I can sketch wireframes and produce mockups all day long, but not all people on the team see or think this way.</p>
<p>There is nothing wrong with a bias towards visual thinking, but it&#8217;s worth recognizing it and remembering that your documentation will need to make sense to others. In my case, I&#8217;ve had a blast sketching layouts and drawing a bunch of squares that represent how users navigate through the product. That&#8217;s helped me get my thoughts out of my head so I can start the process of documenting them. Your process might be bulleted lists or diagrams. Use what makes sense to you and know you will need to translate that work for others.</p>
<h3>Tell a Story</h3>
<p>I have also learned that thinking about features as stories helps a lot.</p>
<p>Think about it: a story has a protagonist (the user) who is finds herself in a situation (the user flow) before reaching an inciting incident (the task to complete) in order to find a resolution (the expected outcome). Who knew Stephen King was a master at writing feature requirements all this time?</p>
<p>My process so far has been to make a list of all the key product features, then tell a story from the perspective of the end user about how they are using each feature. Our team is calling these user stories, and each feature can have as few as a single story and as many as a dozen, depending on the use cases.</p>
<p>User stories are great because they force you to think from a user&#8217;s perspective and to focus on expected outcomes. Let&#8217;s say we are writing the requirements for Account Creation. Here is how we&#8217;ve been framing each user story:</p>
<table>
<tr>
<th>As&#8230;</th>
<th>I expect that&#8230;</th>
<th>So that&#8230;</th>
</tr>
<tr>
<td>[Identify the user]</td>
<td>[Describe the task]</td>
<td>[Explain the anticipated outcome]</td>
</tr>
</table>
<p>Let&#8217;s say we are writing the requirements for Account Creation. Here is how one user story for it might be written:</p>
<table>
<tr>
<th>As&#8230;</th>
<th>I expect that&#8230;</th>
<th>So that&#8230;</th>
</tr>
<tr>
<td>Any new customer</td>
<td>I can use my existing Google or Facebook account to sign up</td>
<td>I can sign-up faster and manage fewer accounts</td>
</tr>
</table>
<p>I will interject here to say that this exercise requires that you have a darn good understanding of who your users are. Sure, the example above is rather generic because it targets &#8220;any new customer&#8221; but thinking through who your users are, documenting their personalities and even going so far as to give them names will allow you to be more specific and contextual when writing user stories. MailChimp has a <a href="http://ift.tt/1lBLEPk">wonderful write-up</a> on their process for creating user personas that was super helpful for me.</p>
<h3>Document User Flows</h3>
<p>If a user story helps set expectations for a feature requirement, then a user flow provides context for how the user got there and where she ends up after completing the task. </p>
<p>Going back to my personal bias for visual thinking, it makes the most sense to me to see this in a diagram. However, I know not everyone thinks like me, so I have been outlining the required steps a user takes to accomplish the task and using a diagram to illustrate more complex flows.</p>
<p>Here&#8217;s how my I might write up a flow for the user story we used earlier for social sign-in in an account creation feature:</p>
<table>
<tr>
<th>User Flow ID</th>
<th>Description</th>
</tr>
<tr>
<td>UF-1</td>
<td>Customer responds to a call-to-action on the marketing site to create an account</td>
</tr>
<tr>
<td>UF-2</td>
<td>Customer chooses to register a new account using a Google or Facebook account on the  Account Sign-Up screen</td>
</tr>
<tr>
<td>UF-3</td>
<td>Customer selects either Facebook or Google</td>
</tr>
<tr>
<td>UF-4</td>
<td>Customer is prompted to authorize the use of their selected account to register an account by verifying her identity</td>
</tr>
<tr>
<td>UF-5</td>
<td>Customer either: </p>
<ul>
<li>Denies the authorization and is directed back to the Account Sign-Up screen</li>
<li>Approves the authorization and is directed to the User Story 2</li>
</ul>
</td>
</tr>
</table>
<p>Notice how each step is given an ID and each ID can branch off into sub-tasks. The IDs are useful for being able to refer to specific points in the documentation when discussing them with others on the team. This can certainly get messy, which is where a nice diagram can come in handy.</p>
<p><img src="http://ift.tt/2nzUtDk" alt="">An example of a user flow diagram</p>
<h3>Document Requirements</h3>
<p>The crazy part in learning how to write requirements is how much forethought is required before you really start getting into the requirements.</p>
<p>Once the feature has been identified, a user story is written, and the flow outlined, I move into the actual requirements, using the same format that was used for user flows.</p>
<p>Again, back to our social sign-in example, some simple requirements might be:</p>
<table>
<tr>
<th>Requirement ID</th>
<th>Description</th>
</tr>
<tr>
<td>RQ-1</td>
<td>A Google Analytics funnel to measure conversions and drop-offs</td>
</tr>
<tr>
<td>RQ-2</td>
<td>OAuth integration</td>
</tr>
<tr>
<td>RQ-3</td>
<td>Options for Facebook and Google</td>
</tr>
</table>
<p>You can be as detailed as you need to be. I try to err on the conservative side and write as many as possible, while trying not to be too rigidly defined that it stifles creative license during design and development.</p>
<h3>Be Transparent With Assumptions</h3>
<p>I&#8217;ve learned that every decision I make is wrought with assumptions. It&#8217;s hard to be aware of everything, but acknowledging anything you might be taking for granted is important because it provides a window into the decision-making process. Documenting assumptions allows others to understand your logic and provides an opportunity to fuel further discussion.</p>
<p>Let&#8217;s document a few assumptions in our running example:</p>
<table>
<tr>
<th>Assumption ID</th>
<th>Description</th>
</tr>
<tr>
<td>AS-1</td>
<td>Social logins are worthwhile. MailChimp <a href="http://ift.tt/SYaVZh">wrote up</a> a compelling argument against using them but that dates to 2012 and they later acknowledged it can be useful, depending on the site.</td>
</tr>
<tr>
<td>AS-2</td>
<td>This TechCrunch <a href="http://ift.tt/2nuP6DC">report</a> from 2015 is still valid that Google and Facebook are the most used social logins and others are too marginal for us to consider for initial launch.</td>
</tr>
<tr>
<td>AS-3</td>
<td>We will store this information and keep a user logged in as long as they are logged into the social account she selected</td>
</tr>
<tr>
<td>AS-4</td>
<td>We will want to encourage this option ahead of the email option because it can save time.</td>
</tr>
</table>
<p>Believe me, I didn&#8217;t realize a seemingly simple task could carry so many assumptions! This can be so helpful.</p>
<h3>Note Possible Constraints</h3>
<p>A constraint is a limitation that may be outside of your control. Trying to pin these down early helps others on the team plan. I have also found it helpful to ask others if they can help identify constraints because sometimes you don&#8217;t know what you don&#8217;t know.</p>
<table>
<tr>
<th>Constraint ID</th>
<th>Description</th>
</tr>
<tr>
<td>CT-1</td>
<td>Google OAuth 2.0 <a href="http://ift.tt/1yRfviK">limits</a></td>
</tr>
<tr>
<td>CT-2</td>
<td>Facebook guidelines for <a href="http://ift.tt/2nuL4LR">web permissions</a></td>
</tr>
</table>
<h3>Sample Document</h3>
<p>I put together a Google Doc that pulls all these concepts together. Feel free to use it as a starting point any time you find yourself tasked with writing feature requirements.</p>
<p><a href="http://ift.tt/2nzOfTO">View Document</a></p>
<h3>Wrapping Up</h3>
<p>I sure hope this is helpful to anyone feeling their way through feature requirements. As mentioned earlier, nothing here is meant to be prescriptive. This is only what I&#8217;ve found helpful in my early journey into product development.</p>
<p>That said, you may find some of these additional resources helpful:</p>
<ul>
<li><a href="http://ift.tt/2m3Hohs">Practical Design Discovery</a>: Dan Brown writes provides a comprehensive guide on A List Apart on how to break design requirements into problem-solving principles that a team can rally around.</li>
<li><a href="http://ift.tt/2lhxPwK">Write a Script</a>: Chris wrote this tidbit in response to a Jeremy Keith post and serves as a good reminder that code requirements can be written narratives that follow the code structure.</li>
<li><a href="http://ift.tt/2nixERC">Sketch vs. Figma:</a> Christian Krammer compared the two apps for wireframing and it convinced me to give Figma a try.</li>
</ul>
<hr>
<p><small><a href="http://ift.tt/2nzQDu8">On Writing Feature Requirements</a> is a post from <a href="https://css-tricks.com">CSS-Tricks</a></small></p>


On Writing Feature Requirements

On Writing Feature Requirements

Top Stories